From nobody Tue Oct 1 08:49: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 B1A241200F1 for ; Mon, 30 Sep 2019 09:33:54 -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_HELO_NONE=0.001, 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 AEHyLceP71pP for ; Mon, 30 Sep 2019 09:33:53 -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 3B4871200D6 for ; Mon, 30 Sep 2019 09:33:53 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id q10so40063690iop.2 for ; Mon, 30 Sep 2019 09:33:53 -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=oJear1CWjVGTLiIpwmkBsQ+Bl7tZLvLZDcj3QeXIWWw=; b=ULuJQN/6xJV8Uo48PE+z0Kb2tnsq2h0lkZs2E3vaJx/nO3BnShZ34/oVh1QhOf6GsM n96VZpyJzZj8MtMHRfGz8zl/1lWq/o5o7or5cZ3WXfQx2a+Vckx8OVAwo9Vkhxa3hfYq v7jKW2sGiBL+HTeemhKCVwsP/T9QCXwI/VMKuUBTP4ACX73GC5xXUyXYSlFokDScZlid ssnnJ12SXDaTFQyJMqkvsQATs24jsUVR/0/UGOR2N1wpewlVqzHA8DfHZr4Ys1zGa/XL 5+5UCDWj3nQ/zewGn044uE7EKxQSkwrkfzzoqvWJmKk1jikTEj7YThStqMXqoZU4smdy Ni+w== 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=oJear1CWjVGTLiIpwmkBsQ+Bl7tZLvLZDcj3QeXIWWw=; b=dXyxaXYJPLs1SgPutQY09U1o47S33Dnm7MQv6S5waU+vC1PbsLIVai2P/pTfULw4yC pJIFTRek22dHe5FwQnqP4v6nTR6QJjAf3u0z1Z/7lDHDQyO0Qe7YBI8sj7gewj//BjaS 1kADdiFfV3T34s0jEar4zMXIW097l2A7fhMqMG0SaPtUKaRuQfInknmYoeX0l1YGG1Nj 8Bcs/FuC78oahk6YTvtktWhOnsgsbKPKxCN2l7Q0ONpKMGTCJOXxVrnrKinH3Ik72is3 lAOm/lX2LEwvZh7AMiarcCrGe+s2XeVXmjzmHC1yBs0S8anvFB4CvCfts/JCMPSvqAk7 J45Q== X-Gm-Message-State: APjAAAW+TViEghwFiBrIXweDCNTqOtpquOek3zg3sjUpUeGHjrIzJ+XK QiwyVAWGyE/iB3zxjOF7Ih5oKb+Dl07f4sdVRbqbMIJr03bLOg== X-Google-Smtp-Source: APXvYqzWPyh9AwjVoqRBrrYPQdNvJz/aWF1I2QqwouKXjoy2Ei/ac0OWEamWsiKx75rT7063xv8zGEuAPXvLy+FqlS8= X-Received: by 2002:a92:ca8e:: with SMTP id t14mr21338964ilo.73.1569861232300; Mon, 30 Sep 2019 09:33:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 30 Sep 2019 23:33:40 +0700 Message-ID: To: Will Hawkins Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000019188c0593c7cde7" Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:49:58 -0700 Subject: Re: [Add] US Congress to investigate Chrome's use of DoT 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, 30 Sep 2019 16:33:55 -0000 --00000000000019188c0593c7cde7 Content-Type: text/plain; charset="UTF-8" I thought the article was very interesting. Here's the first sentence, which is public: "Congressional antitrust investigators are scrutinizing plans by Google to use a new internet protocol because of concerns that it could give the company a competitive advantage by making it harder for others to access consumer data." https://www.wsj.com/articles/google-draws-house-antitrust-scrutiny-of-internet-protocol-11569765637 The inquiry doesn't seem to be about "enterprises, schools, home networks", etc. Just access to consumer data. thanks, Rob On Mon, Sep 30, 2019 at 11:26 PM Will Hawkins wrote: > I thought this might be of interest to people in this WG: > > > https://tech.slashdot.org/story/19/09/29/2033247/googles-dns-over-tls-plans-scrutinized-by-us-congress > > Will > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000019188c0593c7cde7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought the article was very interesting. Here's the= first sentence, which is public:

"Congressional a= ntitrust investigators are scrutinizing plans by Google to use a new intern= et protocol because of concerns that it could give the company a competitiv= e advantage by making it harder for others to access consumer data."
https://www.wsj.com/articles/= google-draws-house-antitrust-scrutiny-of-internet-protocol-11569765637<= /div>

The inquiry doesn't seem to be about "ent= erprises, schools, home networks", etc.=C2=A0 Just access to consumer = data.

thanks,
Rob

On Mon, Sep 30, 2= 019 at 11:26 PM Will Hawkins <whh8b@obs.= cr> wrote:
https://tech.slashdot.org/story/19/09/29/2033247/googles-dns-over-tls-pla= ns-scrutinized-by-us-congress

Will

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000019188c0593c7cde7-- From nobody Tue Oct 1 08:50: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 62E6D1200E9 for ; Mon, 30 Sep 2019 09:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 DA-B2lliMDza for ; Mon, 30 Sep 2019 09:38:35 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 60DB9120043 for ; Mon, 30 Sep 2019 09:38:35 -0700 (PDT) Received: from xse63.mail2web.com ([66.113.196.63] helo=xse.mail2web.com) by mx147.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iEygw-000iuf-MN for add@ietf.org; Mon, 30 Sep 2019 18:38:32 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46hp2n3JTmz6yW5 for ; Mon, 30 Sep 2019 09:37:05 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iEyfZ-0004S2-BD for add@ietf.org; Mon, 30 Sep 2019 09:37:05 -0700 Received: (qmail 19175 invoked from network); 30 Sep 2019 16:37:04 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.205]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Sep 2019 16:37:04 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Mon, 30 Sep 2019 09:37:03 -0700 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Sinatra X-Originating-IP: 66.113.196.63 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.63/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.63/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0dWQ8c9lblW44odAlK6ziUapSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4aExVBpSMWCu7haOdZDs8wfgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+fyO3R7+MmLKUvLY+RGMRrtMm/JD3cPBOX47Hg3FEpDo46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnMW3OYyuYMLR 58Y0/2y47gmw4nyZJPLtTGO226a2zJ/FIosQUXz897cWu1SI7U9/kzKR6RgQ6scM/oDJnhhySxll zsv0qcotRbFdgNvWISigi/jsU5ildGCaI63SvQizCpq7xqDoiTjjGpNS1XGXbXLF+hMY2GbI1wQS 4qiLDPPMS9y9uNbs1DqwO711CiNzcz304hZXe9Hzjq8Wyha4ld1HsJ6pXMtOnAGLbXDPHbbuctgz cDoFd+96Xw4QUNtTnQBuN0O+WUAe5gd/Bp0D6L9VskP8L6ke4vogdy2/otE42fa5Z8JMyvt2otFY eJV5EEl45oFndAaW0zhwtclwNLITiSzBvtjMqHJKbcoJ3LAWa8Mrc8quJ4btPpt/2FLuFDHRLWyH Qs+3RVQ97CmIM68WJB4pGe8YrEHjBXb8vVkXYd/jKzjiuDYHz/0WYr1rU3B7HfKjI1eYNYaA4ur2 /Is= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:50:26 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 30 Sep 2019 16:38:37 -0000 =20 > On Sep 30, 2019, at 8:55 AM, Michael Sinatra wrote= : >=20 > The original article is in the WSJ, so it's probably paywalled. Here's > a free one, but it's just based on the WSJ article: >=20 > https://gizmodo.com/house-antitrust-investigators-now-scrutinizing-googles= -1838601830 >=20 > I am not sure where to start in terms of all the ways in which I > disagree with the antitrust approach... The article mentions one real issue behind the lawsuit: the ISP want to cont= inue being able to sell consumer data to advertisers. So much for the other a= rguments. -- Christian Huitema=20= From nobody Tue Oct 1 08:50: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 9A6521200E0 for ; Mon, 30 Sep 2019 10:12:07 -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 IaT7EzzEMZOU for ; Mon, 30 Sep 2019 10:12:03 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA4F120104 for ; Mon, 30 Sep 2019 10:12:03 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id A76D637401C0; Mon, 30 Sep 2019 10:12:01 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 7D9F717D8931; Mon, 30 Sep 2019 11:12:01 -0600 (MDT) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 77DB917D8930; Mon, 30 Sep 2019 11:12:01 -0600 (MDT) From: Paul Ebersman To: Wes Hardaker cc: ADD Mailing list In-reply-to: References: <20190928153534.B6A7317C8725@fafnir.remote.dragon.net> Comments: In-reply-to Wes Hardaker message dated "Sat, 28 Sep 2019 21:13:02 -0700." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95262.1569863521.1@fafnir.local> Date: Mon, 30 Sep 2019 11:12:01 -0600 Message-Id: <20190930171201.7D9F717D8931@fafnir.remote.dragon.net> Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:50:55 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 30 Sep 2019 17:12:08 -0000 ebersman> Expecting individual device users to be network admins and ebersman> security experts is never going to scale. It's why real ebersman> informed consent is so hard (if not a myth). wjhns1> I actually think that it's more likely users will get their wjhns1> policy bundled with some other software. IE, they install an wjhns1> anti-virus package and one of the things it does is configure wjhns1> the local OS policy to request the anti-virus black list in wjhns1> outgoing DNS requests. I was thinking OS/network stack but sure. AV or similar shim in the stack is close enough. This also makes it more general purpose, since apps (including browsers) would at least have the option of respecting the user's wishes and the OS is in a better place to detect if some rogue app is trying to bypass it. wjhns1> Note that multiple TRR selections would already let users pick a wjhns1> TRR with the right policy. The point of my suggestion was to wjhns1> try and stop tying part of the "trusted" with the "resolver" and wjhns1> separate the functionality. TRRs set by the browser vendor aren't real choice. "we have 3 ice cream flavors, hope you like liver, wood chips or soap flavors" Now I have to vet every app (including browsers) and then vet all their TRR choices. Again, doesn't scale, isn't a reasonable expectation of a user. From nobody Tue Oct 1 08:51:16 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 26CA0120132 for ; Mon, 30 Sep 2019 13:09:21 -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_HELO_NONE=0.001, 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 EwEWcVsa4IWW for ; Mon, 30 Sep 2019 13:09: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 D492612008C for ; Mon, 30 Sep 2019 13:09:19 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 8A07129A06; Mon, 30 Sep 2019 13:09:14 -0700 (PDT) From: Wes Hardaker To: Will Hawkins Cc: Wes Hardaker , Paul Ebersman , ADD Mailing list References: <20190928153534.B6A7317C8725@fafnir.remote.dragon.net> Date: Mon, 30 Sep 2019 13:09:14 -0700 In-Reply-To: (Will Hawkins's message of "Mon, 30 Sep 2019 02:35:18 -0400") 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: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:51:15 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 30 Sep 2019 20:09:21 -0000 Will Hawkins writes: > I agree with you both: users may not necessarily want to (or be able > to) configure their resolver to use lists like this but the software > that those users trust (e.g., AV software, as Mr. Hardaker said) may > do so. I could even see browser having a narrow selection of resolvers (because it takes a *lot* of work to set up a globally viable resolving system), and yet a significantly larger list of options for what filtering source to use to marry with the resolution service (one of which, of course, could be the default for the resolver) . > In addition to offering this option as a way to point to filter lists, > this option can be used to point to locations that will, in turn, set > the filter lists? The benefit may be that the feature is easier for > the end user to configure *and* the delegate organization can maintain > an up-to-date list of filter lists on behalf of its users. I'm not sure what you're describing, since my reading of the above is that's exactly what the draft allows for: pointing at someone else's list to maintain. -- Wes Hardaker USC/ISI From nobody Tue Oct 1 08:51: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 40DA9120143 for ; Mon, 30 Sep 2019 13:24:54 -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_HELO_NONE=0.001, 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 N3BTquAe-gGB for ; Mon, 30 Sep 2019 13:24:51 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 48ED512008C for ; Mon, 30 Sep 2019 13:24:51 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id v8so12836073wrt.2 for ; Mon, 30 Sep 2019 13:24:51 -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=YDsCijIBv+5d32YN11KrqZVJqXRWm/2IPRi9zj3R1kg=; b=numMbvFkoJ1dQE5t2NIvKmxQkH3T42Jwnr2kegX274hcQXiAZUG0okxB2+2bDHpU6S E6r55U/vUptZ9EYmnbKOgHJaXnlg4yjRPnd3yfiJs3anzdVdrcWMwdr/DccsodJa+uOQ caTRWTfYdnBlwEEoANuqXo0WVA30hdc0SepYEmKWI6CLTk0uBZKiEDym9iP/yUo4hECP WwkkdCKT7+/IR9lBaib8WKlI0dszLrhBlVas2DQA5s2mAzqpIcwSTXGtRLneJhyoGokG ahNf2kpS+YOLZ7ygb/FTeYpp5nIXQ2tEYYaUM4o3uwLhQDuhkMRCSTr1cJqcql+su2zC RJPw== 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=YDsCijIBv+5d32YN11KrqZVJqXRWm/2IPRi9zj3R1kg=; b=Yv7Id/gQWTlDQ4SWyxz//Ri1sA1m7f3NL3HgkmSl2A/8y6v4V4Nl6DD/ZDEEdH6SQU 86q7Vps9m/DWR+s6N1WwfGSb48q1CULAN452kVDtN901fiC9P5vv2knkhdZQoBHj0fIB oYZ+tHWkeQLJswoEjWgIRE48ZnxA3DnXhlkRft2E4Gc9kQ028i57DTyeNTop9g4MXjKZ H9tDufqazSAKoqdpSXJrSFsnCd3ndgsAiy6JV65rGafwjCv+db9Un3y0bizeUZWZIuGX HvxPttou1h+ihFMKNA+4gIIU0yajV0KTl50ZdIzqQ1X7Jtk+QDNceuaQQskqQGL5tW2e jBvA== X-Gm-Message-State: APjAAAXtlefG5o6UBBvFQAfyNmM8bASHvdvZ9kyP79Maro5VnUBqrqHe wvIQBx6L6KUFHiiFF4d6MNtzzI0PmUKr/SVrVSKjzw== X-Google-Smtp-Source: APXvYqx8nr6+tl3SQ7jdvmtD3NhHux6B05gZ5XzaX41QYp9NjYB3Se9h4rlepQIADNsBjD7MUtWiMHjQmr9SNb4PiGA= X-Received: by 2002:adf:f8cf:: with SMTP id f15mr14335271wrq.292.1569875089352; Mon, 30 Sep 2019 13:24:49 -0700 (PDT) MIME-Version: 1.0 References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> In-Reply-To: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> From: Eric Orth Date: Mon, 30 Sep 2019 16:24:37 -0400 Message-ID: To: Vittorio Bertola Cc: Wes Hardaker , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000000b68ce0593cb0772" Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:51:34 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 30 Sep 2019 20:24:54 -0000 --0000000000000b68ce0593cb0772 Content-Type: text/plain; charset="UTF-8" I don't think a filtering request like this makes sense completely independently of the resolver selection because I assume most recursive resolvers would never support such toggleable filtering. If the user (or some installed software acting on the user's behalf) decides that antivirus filtering would be good, they can't just add an EDNS0 request and expect it to happen. They're going to have to first ensure all used resolvers support it before requesting it. That said, there are recursive resolvers out there that support user-configurable behavior such as type of filtering. The ones I know of work based on setting configuration on the web with the provider and then DNS requests are matched with either client IP or identifiers in DoH/DoT domains/urls. A proposal like this could be a good way to standardize such ID-matching behavior or potentially move the configuration to client-side if desired. If enough recursive resolver providers are interested in such a standard mechanism, it could make sense for applications or other stub resolvers to implement support. On Mon, Sep 30, 2019 at 12:27 PM Vittorio Bertola wrote: > > > > Il 27 settembre 2019 23:12 Wes Hardaker ha > scritto: > > > > > > I spent some time trying to see what else we could do to better support > > all parties in an ADD world. I wrote up the following in an effort to > > spur thinking in new directions. You'll probably hate it :-) > > > > > https://datatracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-filter-request/ > > Thanks for daring to do this :-) > > My feeling is also that standardization work in the field of expressing, > communicating and implementing DNS filtering lists would help many use > cases (by the way, there already is a de-facto standard for a good part of > this, i.e. RPZ, so it should be part of the picture). However, we also know > that some people here believe that DNS filtering is always wrong, even when > requested by the user. We could still have a standard for those that want > to use it, though. > > Also, you'd possibly need to flesh out a relatively complex architecture. > For example, there are cases in which the compiler of the filtering list > does not want to make it accessible to everyone, and there could be attacks > based on forging/spoofing legitimate lists, so you would want to have > authentication, channel security and access control. > > Then, there is the issue of which filters should be applied, which is a > policy and regulatory one; resolver operators could honor the user's > request for a given filter, but at the same time they might want to do > their own malware filtering on top of it, or they might be required by law > to block yet other stuff. So the communication of active filtering > frameworks could go in both directions. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000000b68ce0593cb0772 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think a filtering request like this makes sens= e completely independently of the resolver selection because I assume most = recursive resolvers would never support such toggleable filtering.=C2=A0 If= the user (or some installed software acting on the user's behalf) deci= des that antivirus filtering would be good, they can't just add an EDNS= 0 request and expect it to happen.=C2=A0 They're going to have to first= ensure all used resolvers support it before requesting it.

<= div>That said, there are recursive resolvers out there that support user-co= nfigurable behavior such as type of filtering.=C2=A0 The ones I know of wor= k based on setting configuration on the web with the provider and then DNS = requests are matched with either client IP or identifiers in DoH/DoT domain= s/urls.=C2=A0 A proposal like this could be a good way to standardize such = ID-matching behavior or potentially move the configuration to client-side i= f desired.=C2=A0 If enough recursive resolver providers are interested in s= uch a standard mechanism, it could make sense for applications or other stu= b resolvers to implement support.

On Mon, Sep 30, 2019 at 12:27 PM Vit= torio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> = wrote:


> Il 27 settembre 2019 23:12 Wes Hardaker <wjhns1@hardakers.net> ha scritto: >
>=C2=A0
> I spent some time trying to see what else we could do to better suppor= t
> all parties in an ADD world.=C2=A0 I wrote up the following in an effo= rt to
> spur thinking in new directions.=C2=A0 You'll probably hate it :-)=
>
> https://dat= atracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-filter-request/

Thanks for daring to do this :-)

My feeling is also that standardization work in the field of expressing, co= mmunicating and implementing DNS filtering lists would help many use cases = (by the way, there already is a de-facto standard for a good part of this, = i.e. RPZ, so it should be part of the picture). However, we also know that = some people here believe that DNS filtering is always wrong, even when requ= ested by the user. We could still have a standard for those that want to us= e it, though.

Also, you'd possibly need to flesh out a relatively complex architectur= e. For example, there are cases in which the compiler of the filtering list= does not want to make it accessible to everyone, and there could be attack= s based on forging/spoofing legitimate lists, so you would want to have aut= hentication, channel security and access control.

Then, there is the issue of which filters should be applied, which is a pol= icy and regulatory one; resolver operators could honor the user's reque= st for a given filter, but at the same time they might want to do their own= malware filtering on top of it, or they might be required by law to block = yet other stuff. So the communication of active filtering frameworks could = go in both directions.

--

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

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000000b68ce0593cb0772-- From nobody Tue Oct 1 08:52: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 58910120096 for ; Mon, 30 Sep 2019 19:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=obs-cr.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 mdpDCWD1Hh4K for ; Mon, 30 Sep 2019 19:06:07 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 19E11120077 for ; Mon, 30 Sep 2019 19:06:07 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id q21so6762483pfn.11 for ; Mon, 30 Sep 2019 19:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obs-cr.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B8dWDBYBve1IGWQ8uCkdueeUpZQh0/toePxa0ELvruc=; b=N5XQW3wcY5bm9LUsu6m9ejqjNExwgKGeZbAy2ExgtaPnUqM3OG8/VLKyq0L5poKqZP 065UC41ad+pyP5qLFFX4E/1qZ4TvnBq0EXRKcs4scu+D3vvA9FAbq7AB7do7q+AHb8rl /G7utyfY6TXwz46aREuvJVCovVzWHZ9THVzeHbSrn4FZ7IQzoe4nJ9oUz6aGYMWnVBAf TqzhDHArKhxcPbdtOunPOIH5CCc2T14qkarabw1llqvDRyyHAgWQh8RixDJT6o2z6qG0 lKiGWPJR03+8liCV7wLX6TTp7ITMDnN3QZhlegglK58zff4Bc8QnmFjdmF/aOyecJDda WtPA== 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=B8dWDBYBve1IGWQ8uCkdueeUpZQh0/toePxa0ELvruc=; b=OOAvJmi/ekeyX4JXI3whfrU+8KIdcBR0JnfJMjH652yZObdp/PPK94Hu3YsXrlYa4h PktZ6ZhvVgDrZhlhuxNVa0nTNRSib5pGugTErOki2X4q5Cta9nWfhm2a/JCTHUDub+nz uvg05W7hJ1bXWuYSMXKwc+IFhkkKNIPr/Hdv5GQp5lX6M8rzxq3/RpPrPvRO75vWwZw/ 0DDmPBLU24CTdUZ66EroZJZVgD14wwyr7WvWE+yeNT68UuQF4oHiykVF1q3XvjtnWVpJ hcUbtgcgpIH4Whwg1HUbgLwzwOgs196vmYswRPBFkWrYUBPacuEh8tnyLQbnKF0A8sWT eezQ== X-Gm-Message-State: APjAAAWlM161oDPFRts/fyL+2eaRKTGnBXlcjNECEtQuyHHn86rMMko3 1f3AU3vaEmYSOrJndsGtUxLUfS+moavl8eW1E0J462rb X-Google-Smtp-Source: APXvYqzCBDt7XAVmIaNtI9yoGmSZeTQsLVifZBqdTCrQ9PdnKTdaJKFCFt6MUCtw5EJO7Mm4en+4g12GAjrcPieNxdE= X-Received: by 2002:aa7:8242:: with SMTP id e2mr25168347pfn.33.1569895566196; Mon, 30 Sep 2019 19:06:06 -0700 (PDT) MIME-Version: 1.0 References: <20190928153534.B6A7317C8725@fafnir.remote.dragon.net> In-Reply-To: From: Will Hawkins Date: Mon, 30 Sep 2019 22:05:55 -0400 Message-ID: To: Wes Hardaker Cc: Paul Ebersman , ADD Mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:52:00 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 01 Oct 2019 02:06:09 -0000 On Mon, Sep 30, 2019 at 4:09 PM Wes Hardaker wrote: > > Will Hawkins writes: > > > I agree with you both: users may not necessarily want to (or be able > > to) configure their resolver to use lists like this but the software > > that those users trust (e.g., AV software, as Mr. Hardaker said) may > > do so. > > I could even see browser having a narrow selection of resolvers (because > it takes a *lot* of work to set up a globally viable resolving system), > and yet a significantly larger list of options for what filtering source > to use to marry with the resolution service (one of which, of course, > could be the default for the resolver) . > > > In addition to offering this option as a way to point to filter lists, > > this option can be used to point to locations that will, in turn, set > > the filter lists? The benefit may be that the feature is easier for > > the end user to configure *and* the delegate organization can maintain > > an up-to-date list of filter lists on behalf of its users. > > I'm not sure what you're describing, since my reading of the above is > that's exactly what the draft allows for: pointing at someone else's > list to maintain. Sorry for not being clear. What I was attempting to suggest was adding support for pointing to a provider of lists of lists. That would allow client C to direct their ISP to contact entity E who will, in turn, provide a list of filter lists. This would allow a separation where entity A has domain-specific knowledge about malware-hosting domains entity B has subject-matter expertise in adware-hosting domains ... and entity E offers a service to its clients to vet those providers and choose the lists that offer a "complete" solution. It is hardly reasonable to expect a single entity to be knowledgeable about all the possible things to filter in the same way that, e.g., stock analysts focus on a specific company or sector and different BL operators generate different lists. I hope that a) that makes sense and b) it's not something possible per the proposed spec and c) I am not wasting everyone's time. Thanks again for the thought-provoking proposal! Will > -- > Wes Hardaker > USC/ISI From nobody Tue Oct 1 08:52: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 3ED5D1200FF for ; Tue, 1 Oct 2019 01:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 az-cBoSwSEVT for ; Tue, 1 Oct 2019 01:08:59 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F61200FE for ; Tue, 1 Oct 2019 01:08:59 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.26.132]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id x9188j6g013050 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2019 01:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1569917337; x=1570003737; i=@elandsys.com; bh=1HMqYGUIOPcQX0kOzS/B+UMhR3UqJRsB4hqMtDqnds8=; h=Date:To:From:Subject:In-Reply-To:References; b=o/JMazJQN+C13dt5sLm7400ivx1cr6f+vo+KeTCm3xy4otSwMP6YVV6iqAooPVZOw 8HY+Mupr48keE0udSrIiM+LS0Yt+u6D/vhoeduEj08iZTu27ZY+mekUDRlVtrYECsN FEC5bGSJLE3zOy/FVNYYP6vQxfcLduDyjblQLzuY= Message-Id: <6.2.5.6.2.20191001002512.136f1428@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Oct 2019 00:55:30 -0700 To: Michael Sinatra , add@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:52:28 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 01 Oct 2019 08:09:00 -0000 Hi Michael, At 08:55 AM 30-09-2019, Michael Sinatra wrote: >The original article is in the WSJ, so it's probably paywalled. Here's >a free one, but it's just based on the WSJ article: > >https://gizmodo.com/house-antitrust-investigators-now-scrutinizing-googles-1838601830 > >I am not sure where to start in terms of all the ways in which I >disagree with the antitrust approach... Please see the letter at https://www.ncta.com/sites/default/files/2019-09/Final%20DOH%20LETTER%209-19-19.pdf I'll skip the antitrust angle. The specification was standardized in the IETF. It can be implemented in application. In this case, it is implemented and deployed in at least two web browsers. One of the points in the letter is about centralization of DNS. One of the web browser vendors stated that it does not want to encourage that. Now, that is viewed as an issue. Regards, S. Moonesamy From nobody Tue Oct 1 08:52: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 960311200CE for ; Tue, 1 Oct 2019 06:24:53 -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_HELO_NONE=0.001, 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 BDlkZu6qF7x9 for ; Tue, 1 Oct 2019 06:24:52 -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 CF217120024 for ; Tue, 1 Oct 2019 06:24:51 -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 DA1F26A234; Tue, 1 Oct 2019 15:24:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1569936289; bh=VD6b2EXG604X2ZsokLqBm9+eYkuLQfgFweeX2WUw3kM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=QNXadMLbR/JbrLrWNtDLCHhv8BlYk9Bxh1psisNKWD6dLmF2KmFkmYN6s2pvqkjnr g4NcvjHitGfsYycV1OSgJeQXVyJd1DCJyaOJibOjHy57ELou5JhCbJOO4NBmuCELP9 NaNQlfSy83Hdr66N/61Y8NDsE5r9/33TiYwu7fNYpmRZ5UMCXCwkbpqpfAgnBmh7Um Wz1afBcNIf7o9B7kt+z9vnHa3ENPLjasN+BlRaA6LQ677hfpMb0vSKPKCYsSype/dM hjn8r/7wCcaAM/Zt6InpZEdd28RSIcFCDwwgHpUkcKrtUjXPLuJmqAqtVK93ugfhJt I0WAolAgJl35A== 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 CE2583C0194; Tue, 1 Oct 2019 15:24:49 +0200 (CEST) Date: Tue, 1 Oct 2019 15:24:49 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Michael Sinatra , add@ietf.org Message-ID: <1207530537.5924.1569936289755@appsuite-gw2.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: X-Mailman-Approved-At: Tue, 01 Oct 2019 08:52:56 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 01 Oct 2019 13:24:54 -0000 > Il 30 settembre 2019 17:55 Michael Sinatra ha scritto: > > > The original article is in the WSJ, so it's probably paywalled. Here's > a free one, but it's just based on the WSJ article: > > https://gizmodo.com/house-antitrust-investigators-now-scrutinizing-googles-1838601830 > > I am not sure where to start in terms of all the ways in which I > disagree with the antitrust approach... IMHO, if Do* deployment is used to push DNS resolution away from ISPs and into the hands of browsers and their business partners, it alters market dynamics on DNS-based services where browsers/public resolvers and ISPs compete for the same customers, i.e. DNS resolution itself and any value-added services on top of it. However, the anticompetitive effect only appears if the browser changes the resolver that the user would otherwise connect to. In the end, a dominant browser pushing users to use a specific DNS resolver is not different from a dominant operating system pushing users to use a specific browser - something that was recognized anticompetitive 20 years ago. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Oct 2 12:11: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 45E78120A34 for ; Tue, 1 Oct 2019 09:00:48 -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_HELO_NONE=0.001, 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 1fTLi7R6CtJS for ; Tue, 1 Oct 2019 09:00:45 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 BBA55120A46 for ; Tue, 1 Oct 2019 09:00:45 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id w144so14886651oia.6 for ; Tue, 01 Oct 2019 09:00:45 -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=CZYgPGpMm/KwsHDmTtEzMH+zg+aqxfL4lmjD5zU6rxE=; b=S0jJC3SbUSdjRQUuakah9s7sImoay5Mse03whduQ8HcY3OTyxutiQG9NWXOSjeGkNo UEYjHJXfXOVcdmmcSnBtVBP+Fx0g4rQNFYdyq2nmPgUcQGGK5AngKUbcm+at/5SiO04+ SNAX2BZD4gGOO0CGiCo1jm+tC4mMR0+LL3xghgLhVKsRvXPAgEGnLWjJFX19aE8Iq58i pPZ+V2zEXBLMeaMA6kPuirww3wHCgsYpx5pRVEWKCFkq9Cae2PPmIuHE16zXajovyIT8 +Ny/y2EippfOJ4Cnbkf2TlvWnuhnmuSISKREWm0IPaDSEyd7EeX7ZolkQzgUhOXtFosu epVw== 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=CZYgPGpMm/KwsHDmTtEzMH+zg+aqxfL4lmjD5zU6rxE=; b=nliD+1Kh9affZwhVdlgB7bzbB+wjZpYwssjzX3hBlK64vOquVO5v24a6HcgY6XrcI/ 4HkBFl4gous3sPCNl2oMmYs81TVIRYGpLVwC0s6aPXDoEzkeDxmAacuHxlQSDRvq6cD5 34Wm9nzercw5WTrgCURMVrAWhTI2Lb/vPzyvvQRvWxKYwZyKAKOSC+1tC+xzJemQVJJt A/Y8nTnbUAR3l/q7+AYjsb+41rg96f75CWfCBvry+B3ZfZvkwCpJiP23VG9JS/cgtaXl siigDHE0WAZBLy6zSY9KhjfFn3TbBDomRfaC5bBA7QSZRjBU2nPfYv6UZ/yo6UoOGAjU VDvg== X-Gm-Message-State: APjAAAW4uHQgt/FidgQu9EJ5MI+bI51fJ9iGW++W9gqwe864ud7galKq 5jW59i6vK98C9fd7XgEs4gthfnafvJanlOxnrfpwzw== X-Google-Smtp-Source: APXvYqwuXum1CXS9YVjfsHT3y2gSaX6s+kdf2c0vXMiUCr+0DdY/nrdyZsYZLKdefp2qShMTOJjYhwfeKeU7dEFx6eQ= X-Received: by 2002:aca:4dd1:: with SMTP id a200mr4267413oib.94.1569945644603; Tue, 01 Oct 2019 09:00:44 -0700 (PDT) MIME-Version: 1.0 References: <1207530537.5924.1569936289755@appsuite-gw2.open-xchange.com> In-Reply-To: <1207530537.5924.1569936289755@appsuite-gw2.open-xchange.com> From: Kenji Baheux Date: Tue, 1 Oct 2019 18:00:33 +0200 Message-ID: To: Vittorio Bertola Cc: Michael Sinatra , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000076fc0b0593db749e" Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:11:39 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 01 Oct 2019 16:00:53 -0000 --00000000000076fc0b0593db749e Content-Type: text/plain; charset="UTF-8" We have said several times in multiple places that we have no plans to change the user's DNS provider (email sent to DNS related IETF ML, replies to press articles, blog post, etc). Color me puzzled. On Tue, Oct 1, 2019 at 5:53 PM Vittorio Bertola wrote: > > > > Il 30 settembre 2019 17:55 Michael Sinatra ha > scritto: > > > > > > The original article is in the WSJ, so it's probably paywalled. Here's > > a free one, but it's just based on the WSJ article: > > > > > https://gizmodo.com/house-antitrust-investigators-now-scrutinizing-googles-1838601830 > > > > I am not sure where to start in terms of all the ways in which I > > disagree with the antitrust approach... > > IMHO, if Do* deployment is used to push DNS resolution away from ISPs and > into the hands of browsers and their business partners, it alters market > dynamics on DNS-based services where browsers/public resolvers and ISPs > compete for the same customers, i.e. DNS resolution itself and any > value-added services on top of it. However, the anticompetitive effect only > appears if the browser changes the resolver that the user would otherwise > connect to. > > In the end, a dominant browser pushing users to use a specific DNS > resolver is not different from a dominant operating system pushing users to > use a specific browser - something that was recognized anticompetitive 20 > years ago. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > -- Kenji BAHEUX Product Manager - Chrome Google Japan --00000000000076fc0b0593db749e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have said several times in multiple places that we have= no plans to change the user's DNS provider (email sent to DNS related = IETF ML, replies to press articles, blog post, etc).

Col= or me puzzled.

On Tue, Oct 1, 2019 at 5:53 PM Vittorio Bertola <vit= torio.bertola=3D40open= -xchange.com@dmarc.ietf.org> wrote:


> Il 30 settembre 2019 17:55 Michael Sinatra <michael@brokendns.net> ha scritt= o:
>
>=C2=A0
> The original article is in the WSJ, so it's probably paywalled.=C2= =A0 Here's
> a free one, but it's just based on the WSJ article:
>
> https://gi= zmodo.com/house-antitrust-investigators-now-scrutinizing-googles-1838601830=
>
> I am not sure where to start in terms of all the ways in which I
> disagree with the antitrust approach...

IMHO, if Do* deployment is used to push DNS resolution away from ISPs and i= nto the hands of browsers and their business partners, it alters market dyn= amics on DNS-based services where browsers/public resolvers and ISPs compet= e for the same customers, i.e. DNS resolution itself and any value-added se= rvices on top of it. However, the anticompetitive effect only appears if th= e browser changes the resolver that the user would otherwise connect to.
In the end, a dominant browser pushing users to use a specific DNS resolver= is not different from a dominant operating system pushing users to use a s= pecific browser - something that was recognized anticompetitive 20 years ag= o.

--

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

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add


--
Kenji BAHEUX
= Product Manager - Chrome
Google Japan
--00000000000076fc0b0593db749e-- From nobody Wed Oct 2 12:12: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 D7F1E1208C3 for ; Tue, 1 Oct 2019 09:30:27 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com header.b=KaIM9/Hq; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=lvoO0NGz 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 5PGsSwOTUlgW for ; Tue, 1 Oct 2019 09:30:26 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 D27DE120855 for ; Tue, 1 Oct 2019 09:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1569947424; x=2433861024; 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=a1q7tnjjftSWzd/HxMq+/x9hKtzOv6nJ4rfjseGMKjY=; b=KaIM9/Hqhb2RmPOjdAIiDiRlG0TxZ+TCei56DE9flaWY3QxdjSzsBhlg6SjpdNG9 ssJ7EUmD0DALHMSvGwHo85TKyUdQR9eVGGIc3VpOlrtTxtaVpfRZmuraCRp88ZsO 2MrBKfmTJ0uzt2hLtuABDoY9akx67CZCNbKUMwrnZNe1gyBpVida7WnkK7IMch1f K2Ym4OI0yJM+cXyC6sopUMPHLUWxaWOvVCf6QRi1yzywYkApKBiOqusjdBOdwSu5 1s2EGDwozhpACrhbtauJJV8V3Vrw2m9AnOtmlZia10SLSb/8U11HRVIT4QvcWR4s MuaywQzu7DahacYitShoTA==; X-AuditID: 60721c4b-8fbff7000000be6c-8c-5d937f20502b Received: from PACDCEX16.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id BD.B4.48748.02F739D5; Tue, 1 Oct 2019 12:30:24 -0400 (EDT) Received: from PACDCEX43.cable.comcast.com (24.40.2.142) by PACDCEX16.cable.comcast.com (24.40.1.139) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019 12:30:23 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX43.cable.comcast.com (24.40.2.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 1 Oct 2019 12:30:23 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.58) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 1 Oct 2019 12:30:17 -0400 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4054.namprd11.prod.outlook.com (10.255.161.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Tue, 1 Oct 2019 16:30:16 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3%7]) with mapi id 15.20.2305.022; Tue, 1 Oct 2019 16:30:16 +0000 From: "Livingood, Jason" To: Christian Huitema CC: "add@ietf.org" Thread-Topic: [Add] DoH/DoT subject of antitrust inquiry Thread-Index: AQHVd6wR8vWn9s7wMkSs3nxbsMogyqdEazuAgAFNYIA= Date: Tue, 1 Oct 2019 16:30:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jason_Livingood@cable.comcast.com; x-originating-ip: [2001:558:1438:aa::5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 689e55db-4da4-48bd-07fa-08d7468ca467 x-ms-traffictypediagnostic: BY5PR11MB4054: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(136003)(346002)(39860400002)(396003)(376002)(189003)(199004)(6512007)(6436002)(316002)(6116002)(478600001)(6916009)(14454004)(33656002)(25786009)(6246003)(8676002)(81166006)(81156014)(8936002)(91956017)(71200400001)(71190400001)(76116006)(58126008)(66476007)(5660300002)(4326008)(66446008)(64756008)(66556008)(66946007)(46003)(486006)(53546011)(186003)(11346002)(446003)(2616005)(476003)(6506007)(2906002)(7736002)(80792005)(229853002)(6486002)(305945005)(86362001)(76176011)(558084003)(102836004)(99286004)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4054; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Hhdjm7BHPKNgSSoUmceLRrFAEa6EFpq0+qTSlC3n82RVmjruvZNi9gSgfr08Kee6ywavC4tY9Bv+1QxhC/RXRHpkL0VFz/M9sE0cuwOl7Kf3Y3KxXZO2jTHhZUB/eYE82QdsjMi3GwJUqKD/Cks+Ie9Ncy9qySuMxJMkf9eN2i1AU6pThTZFQUY1GCsLEb2GsI3P3tqGg6NH80kY4C/gAf49lT9mrPRCA0QOrLbtwzYcwTlmG7Nas8jESCq3NmgnY2meUoWSXMSAlDhDN3065AQ7hVSO4+2K2zLylvgvHEvupFrw1+K3+giBgdHvjbqLuPNQi8CbRoiVKV53wvC5/2asURvkldmBp05JPVX7qD81hSFXqMbCPkqZEsYu1N+2MkmKRzjCPtetqakDQEqsIi8U62G4ZMKxnJ0SEGimanU= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KijgaxVQJoBr1PiTrgliIctxTQMwQFIK+GvxY/onzVSbZAITpspd4OjnYJmkyDK2Au3YOCpcGNQAThSFCv18lpcEfw+1XKzBXVFn49qeFzijAJbQdFM/BbY/NUPFPiRzZOP2Ik2vNF6+yTAMkzzB7ZM9daCSYyrtbkxtJqLkqiqPVAaSxoA10WBD0Imh9OKusQY9Rzzp+zTmODKPXh6dvBzZmd3Ygpcko+p9GmVdvRpcMcNAcdD05zrLn+Vc01evj8Sn6/eoGi+/rNUN+XA3HfH+k3sbSp+Rdav5pwRCruTf21lufY7Fv6eTSsVYFLHEHyEmRhGjRr3GDXBcHPGASw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3wecljQjdBNPIekptqEKO3fhcfdJoDRTvVgIH3rruZk=; b=ijZaqH97qlHdt4g8wlyCq5ilmxF2i1s0SKdpPm9WX5ihnMEiEm/fIx6ux8XLs0+M8/rXyJFzMy58yIzP1xj77CiWJcPLvvZFU9VPeg0yryWJtM5h8iX+1nl4owV/HkLBcyLTP71OsSHbIBXvGGTi1ntF2iDCJdNuUVtwkAYjyFdgQI5sZZ7i7EuBP2aHVHySXF5aC4N/TcbKCtKaA0IjAddr4AaiyHHD0qjbdPr9mq17tVwpI1kI79Ev/2UCOlfpK0ugwri8G8pzgTZ8xUEBtblh3DkrV8z+X/dOR3HpghXN6+iav42lqPH5iHHO5jDwdW6jQeOELcrjpxv+guBrEA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector2-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3wecljQjdBNPIekptqEKO3fhcfdJoDRTvVgIH3rruZk=; b=lvoO0NGzavEE/NkKPyT6DboEesd2XE9RO2yPe52fxGZ7JclTlmS1Meb2ZxalzjsxiKaUsAiG4QCef/1HrEOAO9sz5OJFnmZOz5/tHsuTMU7w61e43PfONvC7k8sbMkxoz2Wr0r21o2v2NwNipcp9STuN7uFHJzsfXCEfIk++468= x-ms-exchange-crosstenant-network-message-id: 689e55db-4da4-48bd-07fa-08d7468ca467 x-ms-exchange-crosstenant-originalarrivaltime: 01 Oct 2019 16:30:16.1367 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: m7w/QW51UJSQsn4+Rk3IQb6PeiQiDh/0oAuHIFe3dWYxBc5vkghEcdJJ8zrSxxC0moai3SIIEdynq5QMiGB9brBFtVlMbvii+P6B/TWmcDk= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4054 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <84F98DD34976384B9A6B287C9E76E9A3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNKsWRmVeSWpSXmKPExsWSUOxpoatQPznW4MUhY4v/p9exWUxunM3u wORxa8YpFo8lS34yBTBFNTDalGQUpSaWuKSmpeYVp9pxKWAAm6TUtPyiVNfEopzKoNSc1ETs ykAqU1JzMstSi/SxGqOP1ZyELqaMFZ3TGAtuMVds/TuRtYHxDHMXIyeHhICJxI/bDexdjFwc QgIHmSQmv7vICOHsZJRYtuUiC4RzhVHi+Y91bCAtQgJHGCVOznCCSExikjj2/CkrROIho8SO fXogNpuAmcTdhVfAdogIaEusmX2PCcRmFlCUeDnlBzuILSxgLvFz+wmoGguJiXdmM0HYVhLr l/eBxVkEVCTmrNwEZvMKuEi0XbnBArGrVGLJ2cNgNqeAvcSmpbvAbEYBMYnvp9ZA7RKXuPVk PhPEnwISS/ach/pZVOLl439AN3NwiAroS8y4qwXRmiKxuGsRVLm6xNNrM9ggbFmJS/O7GSFs X4kHP75AjdGSWPz7EyuEnS1xo/0olK0m8W3bEhYIW0ai79gjNlBYSQicZ5Xo2nSUHWSvkECW xNurdhMYTWchuXQWUIZZQFNi/S59CNNDYlN7wSxouE3pfsg+CxwOghInZz5hWcDIuoqRx9JM z9DQRM/IQs/cdBMjKEkWyXjvYFz30/0QowAHoxIPb3T+5Fgh1sSy4srcQ4wSHMxKIrw2fybF CvGmJFZWpRblxxeV5qQWH2KU5mBREuc9dL4nVkggPbEkNTs1tSC1CCbLxMEp1cAoXPhlm3T5 ogONGW92zn3i/jbziUv0CecHt9aEG+3jFbIW38EkLxN70eJVU0ZsrJd717kX6tPPBISH2B1T nygy11b0/kzlBimu3b5R6xWYNTbuVzzyNk5SNGBD6wrP6bGvLa1P/DP4UeHD82nxqstLo2S+ rWz8LvayP+XTbK6DfF8UGAQv7bihxFKckWioxVxUnAgA6DblT44DAAA= Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:12:08 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 01 Oct 2019 16:30:28 -0000 T24gMTAvMS8xOSwgMTE6NTEgQU0sICJBZGQgb24gYmVoYWxmIG9mIENocmlzdGlhbiBIdWl0ZW1h IiA8YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGh1aXRlbWFAaHVpdGVtYS5uZXQ+ IHdyb3RlOg0KPiAgICBUaGUgYXJ0aWNsZSBtZW50aW9ucyBvbmUgcmVhbCBpc3N1ZSBiZWhpbmQg dGhlIGxhd3N1aXQ6IHRoZSBJU1Agd2FudCB0byBjb250aW51ZSBiZWluZyBhYmxlIHRvIHNlbGwg Y29uc3VtZXIgZGF0YSB0byBhZHZlcnRpc2Vycy4gU28gbXVjaCBmb3IgdGhlIG90aGVyIGFyZ3Vt ZW50cy4NCg0KSU1PIHRoZSBhcnRpY2xlIGlzIGluYWNjdXJhdGUgb24gdGhhdCBwb2ludC4NCg0K DQo= From nobody Wed Oct 2 12:13: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 C2FEF120180 for ; Tue, 1 Oct 2019 10:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=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 MUBaHyXE2RS6 for ; Tue, 1 Oct 2019 10:11:49 -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 8E89112081E for ; Tue, 1 Oct 2019 10:11:49 -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 x91HBfTd039306 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 1 Oct 2019 13:11:44 -0400 (EDT) (envelope-from michael@brokendns.net) Received: from nofx.lbl.gov (nofx.lbl.gov [IPv6:2620:83:8000:107::f]) (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 29C6B645F0; Tue, 1 Oct 2019 10:11:39 -0700 (PDT) To: Christian Huitema Cc: add@ietf.org References: From: Michael Sinatra Message-ID: Date: Tue, 1 Oct 2019 10:11:38 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [162.217.113.18]); Tue, 01 Oct 2019 13:11:45 -0400 (EDT) Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:13:03 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 01 Oct 2019 17:11:52 -0000 On 2019-09-30 09:37, Christian Huitema wrote: > > >> On Sep 30, 2019, at 8:55 AM, Michael Sinatra wrote: >> >> The original article is in the WSJ, so it's probably paywalled. Here's >> a free one, but it's just based on the WSJ article: >> >> https://gizmodo.com/house-antitrust-investigators-now-scrutinizing-googles-1838601830 >> >> I am not sure where to start in terms of all the ways in which I >> disagree with the antitrust approach... > > The article mentions one real issue behind the lawsuit: the ISP want to continue being able to sell consumer data to advertisers. So much for the other arguments. The best anti-competitive angle that I can come up with (from the perspective of the authors of the letter is, "if Google can monetize this data, we should be able to do so as well." But the letter seems to mis-characterize what Google is actually doing: "When a consumer or enterprise uses Google’s Android phones or Chrome web browser, Android or Chrome would make Google the encrypted DNS lookup provider by default and most consumers would have limited practical knowledge or ability to detect or reject that choice." This seems to conflate Mozilla's Cloudflare-by-default policy with what Google Chrome is doing, which I read as something more along the lines of opportunistic encryption (if the user's configured DNS resolver supports DoH, use that). The letter leads with encryption as the major change, which appears to have encouraged the media to pick this up as somehow an "anticompetitive protocol," which I would also say is a mischaracterization. As has been pointed out on this and other lists, the protocol isn't the issue for the most part, it's the application defaults. *If* someone with a large browser market share were to use the browser to direct encrypted data toward a service they own, that could be seen as anticompetitive. But nobody is doing that--not yet. So the letter is either wrong or it's a pre-emptive strike, akin to saying "if Google, or anyone else, is thinking about doing this, don't." michael From nobody Wed Oct 2 12:13: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 6370E1200BA for ; Tue, 1 Oct 2019 10:45:47 -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_HELO_NONE=0.001, 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 uzUQU4YVgB5H for ; Tue, 1 Oct 2019 10:45:45 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 0CC3212009C for ; Tue, 1 Oct 2019 10:45:45 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id z9so3445664wrl.11 for ; Tue, 01 Oct 2019 10:45:44 -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=zFs0XreKXVtiX5t1Y3oiRmtKTtSlf3cODZl/BPR2SNw=; b=Nti7xZZyPiR7PZScapZVI11TgSQ8yHSk3vtwAOZ4TTqpLZhhnB5wc2APcq3DT+rbyM unxVg2mp/3vdNBtRblo6jKxw4kFsG2igqWLBF6Ivhyk2q1qHUhoPnLL236wY44/lvI8L JPY4gZulOb6elBYud5nO1tPDinHWBcSnMqqOguP4i+3i+YayH+o2E/AxqZDx92VTwOHo KsbGL4d3dI1gX+Cyzj45FKkgg3b5nTVbu4sjwQoO5KxrDRIIr5v033gGqTQ4QE8Zwxd6 q6XN2Ic/wp2J1/v3IYGzX3n2vYS/CbMjQAFkvYQqfX5CG7D08Xq9e0V4rJHq/nLH2CfP huYA== 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=zFs0XreKXVtiX5t1Y3oiRmtKTtSlf3cODZl/BPR2SNw=; b=MgBg6MrjbrzqpA6jMaXsuPSh5LD9Jsx+dLA2lRFyYshJYzYI07lE3dWR1p+qOKnG+D X7bsZJoU+tPs+zlA3IykXgGWpwbWobXkyx9OoYn8jzhqvCwjP4bmvh9impOBMoBaptKj tNYWis12lh3gxE+ROAvYeZ1Gs5Aopuq6heIjX22b9OeM+MzleOuBNcKrR1U5pV6PL5lD k7NBkMrPM2YdHWZi1D25jXgP61Ssn/vGK7tb8Hmo/Y2j+LgO4m71CCaPk7DExOBnFaR5 RioH+hOaH0vPcLZ6Y69uqHArRC2t7rfDe0rDmoPC0QQbXShKsLgHQkIROnLG8Wqtt36z iW0w== X-Gm-Message-State: APjAAAV+3yAVWsP91tArXu/unppD3MQ73YKkLqlJMzspCBQROkSwpYY+ hzyYNZdfoX+rk1nAolPjQG4AtbXPbtaMXwufj9zvAg== X-Google-Smtp-Source: APXvYqy5xe4Kq4AyWPx/ArI4s+0L//4awnXazmGA5+acYNviLkMT2EVnZ28T81WLvCYvZriN8pqk+yy0FR4XIOON9LU= X-Received: by 2002:adf:ee4d:: with SMTP id w13mr17719960wro.90.1569951943047; Tue, 01 Oct 2019 10:45:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Kline Date: Tue, 1 Oct 2019 10:45:31 -0700 Message-ID: To: Rob Sayre Cc: Will Hawkins , ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000eb29d20593dceb22" Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:13:31 -0700 Subject: Re: [Add] US Congress to investigate Chrome's use of DoT 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, 01 Oct 2019 17:45:47 -0000 --000000000000eb29d20593dceb22 Content-Type: multipart/alternative; boundary="000000000000e1ad040593dceb85" --000000000000e1ad040593dceb85 Content-Type: text/plain; charset="UTF-8" Which basically exposes the perceived value of the users' data in the first place: encrypt it and some folks are willing to stoke antitrust investigations for the loss of access to it. On Tue, 1 Oct 2019 at 08:50, Rob Sayre wrote: > I thought the article was very interesting. Here's the first sentence, > which is public: > > "Congressional antitrust investigators are scrutinizing plans by Google to > use a new internet protocol because of concerns that it could give the > company a competitive advantage by making it harder for others to access > consumer data." > > https://www.wsj.com/articles/google-draws-house-antitrust-scrutiny-of-internet-protocol-11569765637 > > The inquiry doesn't seem to be about "enterprises, schools, home > networks", etc. Just access to consumer data. > > thanks, > Rob > > On Mon, Sep 30, 2019 at 11:26 PM Will Hawkins wrote: > >> I thought this might be of interest to people in this WG: >> >> >> https://tech.slashdot.org/story/19/09/29/2033247/googles-dns-over-tls-plans-scrutinized-by-us-congress >> >> Will >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000e1ad040593dceb85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Which basically exposes the perceived val= ue of the users' data in the first place: encrypt it and some folks are= willing to stoke antitrust=C2=A0investigations for the loss of access to i= t.

On Tue, 1 Oct 2019 at 08:50, Rob Sayre <sayrer@gmail.com> wrote:
I thought the article was very inter= esting. Here's the first sentence, which is public:

"Congressional antitrust investigators are scrutinizing plans by Goog= le to use a new internet protocol because of concerns that it could give th= e company a competitive advantage by making it harder for others to access = consumer data."

The inqui= ry doesn't seem to be about "enterprises, schools, home networks&q= uot;, etc.=C2=A0 Just access to consumer data.

tha= nks,
Rob

On Mon, Sep 30, 2019 at 11:26 PM Will Hawkins <<= a href=3D"mailto:whh8b@obs.cr" target=3D"_blank">whh8b@obs.cr> wrote= :
I thought this= might be of interest to people in this WG:

https://tech.slashdot.org/story/19/09/29/2033247/googles-dns-over-tls-pla= ns-scrutinized-by-us-congress

Will

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000e1ad040593dceb85-- --000000000000eb29d20593dceb22 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMBMLrMR7h9YjR8U4/MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDUxMTA2MzcyMVoXDTE5MTEw NzA2MzcyMVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAIzvCZRYLgadqUeydXNClNcpp0n53ELy/HcLruB13xvxxIBN/ttsev7i GAEdHsf7onTDWUwPFcROr8DiA6mA1/A1w/kImnZ/QAf7HsRvsEj5Y5oaefxk658HhBqqpJEkRdWe u6sxrMYSwss5RhScJmurP/pXIQALbexgl7dvcNtqFR5QM5VpIVCrw4HYbSSFH1Cq+hByCa8a3soW CVDLTedx4jeBdqhbuqXy8KlOU3QHjL0aYbROgRTwRv0j/TWlqMvSxaasFWy6WqU1ULYZ+1eDE6Ig nfqlBvxUpcfy+zgS8NwkCt6Rrf+FNzN2th9Lapizgq+YyuXarLRkM2tqM+kCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTOji1Lw0P4qSg4yeWN6IYVO0d4RzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAqgjTZi5G/vTnxGbUTtv2XK2olwbJ ShTu7xlOazHIpyxv13LrAN6E6mQDJru0C3XIfpsATPkCmfzn9g359Xn5dAM/I7J/ZYdLKej2PgSt prFNjlZ2os3ou4P1GmQlnL3qSlMJY9gDaaUhGbWRAxfZ0riXf0jKbczh9sMxTZdT0pBEqrQryQCn l+5qV0XCvZlIFgGDOpYr0w4eaccFRgV9U1QhUx8St+aUoxPPYaAWZc6G7E3h5VwUGbdRHDL3TvU0 D09bY4P7ZOMlozsa7sw2IkYoawbedDp33z0i3GMNxnHvZIQ434AMYEDibrNMT6nYgbODQjlReDEe x0E6TeYoETGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDATC6zEe4fWI0fFOPzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgwPSLnxjMIkScOL5rrml7LPACPNW4Y9kt D8pbcPm2pYwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMDAx MTc0NTQzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACKUdYVDVPF3A204Kh07rE8UW4ye/SvP+uWb9+PIKsYqR+N2nmMi Dokl3xmnaifE6lpuAp0RtTRgHNIafIETwOmVJZhuBpc+HiXmXCMuEsrVZIjQCqV5kwrilaXl9X9B OoAWrAlxxSiaK4UsTlMNxKEM5D8kPUKAG9NRZtZOQtPXTE6Bv0A31pF8FTH6nUXT+gOJgTueVtwc mp4CGJH2IEv1gRUHDZ3pfhxgb1zUJyShUSqmLuwt4/7OR9AAtZFjqiy9wdRcmAxWCsU8U1dGzPoc WL8qCasHBrLahvMndcJmxLFFSCJE3GaGp+287p61RnFBAsfRCdk/R+/BB4f8B80= --000000000000eb29d20593dceb22-- From nobody Wed Oct 2 12:13: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 D88961200BA for ; Tue, 1 Oct 2019 10:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=UR+7M7Xq; dkim=pass (1536-bit key) header.d=taugh.com header.b=GMBWCLlY 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 FyQIv6ho48xh for ; Tue, 1 Oct 2019 10:54:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E6CB512009C for ; Tue, 1 Oct 2019 10:54:29 -0700 (PDT) Received: (qmail 85306 invoked from network); 1 Oct 2019 17:54:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14d37.5d9392d4.k1910; i=printer-iecc.com@submit.iecc.com; bh=VDse0NcywHVAp6Ob+1cXb139QKuTBmt7KX8DmoKVVgc=; b=UR+7M7Xqeyx96Mih6UvJE3H04xyJVdFJWkT892g03JvdrmoPBIt1tu3JbvhqiBnvRdzfkO4SaGgmvO6wkEUsO2GjSKbtkf/cQkpwXPhWYCNyJeVrhfAJW4pv3VT28D3Hhj9dl4XD0IggWAPkquko+6Am0LnqhH4lI/5iZUjyLORTjHiLZK6BnYL4FIcK2LQsWVfI49q8xk5vCigwp0nJvDVTPcHO926wPWSd9gHKu+FEIqv0cRPKatUYE9vsSQEB DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14d37.5d9392d4.k1910; olt=printer-iecc.com@submit.iecc.com; bh=VDse0NcywHVAp6Ob+1cXb139QKuTBmt7KX8DmoKVVgc=; b=GMBWCLlYS6u+RM0bVf8+tTs9cnRbG6xlXIdrRtX/5B6C4U1VS61yBhQOkNmbyFwOr3Op9u1DWaJeOPS/1o4BsR+6Hx8PhO+8eSkTijrgJ5f8CTRHXT6NjGh2ieUfzkE4hF0HMwDybRKgLxBKjDdIF+OZMVmZQh3VkaAe1FOOXQCBDnhkh7CnDH/IGNtzbSyharrDvfdYKX2I+rb50+iGCc2QAaoKPLWBoucSJ395bzz4eEonWiebK9VrHqyQuevn Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 01 Oct 2019 17:54:27 -0000 Received: by ary.qy (Postfix, from userid 501) id 3B038B790C8; Tue, 1 Oct 2019 13:54:26 -0400 (EDT) Date: 1 Oct 2019 13:54:26 -0400 Message-Id: <20191001175427.3B038B790C8@ary.qy> From: "John Levine" To: add@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:13:56 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 01 Oct 2019 17:54:32 -0000 In article you write: >-=-=-=-=-=- > >I don't think a filtering request like this makes sense completely >independently of the resolver selection because I assume most recursive >resolvers would never support such toggleable filtering. Agreed. The filter rules seem like a half hearted version of RPZ, which is already painful enough to configure, and it's hard to imagine why a network operator would want to go to all that hassle. If it were me, I'd say you get what you get, and if you want something else, use 8.8.8.8 or someone with the same taste in filtering you have. Also, as has been noted once or twice before, a lot of DNS filtering is policy based, and the provider has no interest in making it easy to substitute someone else's policy for its own. R's, John From nobody Wed Oct 2 12:14: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 36B47120859 for ; Tue, 1 Oct 2019 11:25:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 erRsTa9ziY4d for ; Tue, 1 Oct 2019 11:25:12 -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 5A862120854 for ; Tue, 1 Oct 2019 11:25:12 -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 5F0576A28A; Tue, 1 Oct 2019 20:25:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1569954310; bh=bMKrEfc9yVHIZFhF3KDeo0Oryw4miRJvOWpH6u1OkZQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=knV7vjPHGJX/uT6nCrAysNl0x/XOh1xqfe2/L6TKs9mxZVaHEKaiPpje9seNb/vio FQYd1116chb6jjflLLF/vhfrTd/p8YGWM9DEX5xc2HX68DQKAMk+/1QpTcEi4XgZCQ lhr5FwwPtJBUy/2w8mUeqfrdc8zVQ0FpEeVlfs0oKuJ7WLeS8qol9le5gYUp4VyIsL 8lWsw6k5D0wfuOvYIYw49PMfxfo9t7dKHtJo9NpTRsEZgZJ/vaECD7mFTH0ayvUhVV 53kpSQXo67qOFV/6urmBrVOxejXaiuyhPGmdLt3EFmyud4m8hWI2nDFmsvsNv6KseL k1UWemCOeMYWA== 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 525733C0194; Tue, 1 Oct 2019 20:25:10 +0200 (CEST) Date: Tue, 1 Oct 2019 20:25:10 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Kenji Baheux Cc: Michael Sinatra , ADD Mailing list Message-ID: <995376675.7195.1569954310242@appsuite-gw2.open-xchange.com> In-Reply-To: References: <1207530537.5924.1569936289755@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:14:22 -0700 Subject: Re: [Add] DoH/DoT subject of antitrust inquiry 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, 01 Oct 2019 18:25:18 -0000

Il 1 ottobre 2019 18:00 Kenji Baheux <kenjibaheux@google.com> ha scritto:


We have said several times in multiple places that we have no plans to change the user's DNS provider (email sent to DNS related IETF ML, replies to press articles, blog post, etc).

Color me puzzled.
Yes, I also don't understand why those people are aiming at Google on this. One could argue that the matter needs to be discussed in general anyway, since at any time in the future any browser could change the policy and adopt one that affects competition. But presently, I think that the only approach which raises this kind of concerns is Mozilla's.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Wed Oct 2 12:14: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 817C0120812 for ; Tue, 1 Oct 2019 13:36:35 -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_HELO_NONE=0.001, 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 6Tw3sD4KAf9v for ; Tue, 1 Oct 2019 13:36:34 -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 0C7B9120809 for ; Tue, 1 Oct 2019 13:36:33 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 090B029FF0; Tue, 1 Oct 2019 13:36:27 -0700 (PDT) From: Wes Hardaker To: Will Hawkins Cc: Wes Hardaker , Paul Ebersman , ADD Mailing list References: <20190928153534.B6A7317C8725@fafnir.remote.dragon.net> Date: Tue, 01 Oct 2019 13:36:26 -0700 In-Reply-To: (Will Hawkins's message of "Mon, 30 Sep 2019 22:05:55 -0400") 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: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:14:43 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 01 Oct 2019 20:36:41 -0000 Will Hawkins writes: > Sorry for not being clear. What I was attempting to suggest was adding > support for pointing to a provider of lists of lists. > That would allow client C to direct their ISP to contact entity E who > will, in turn, provide a list of filter lists. This would allow a > separation where Ahh.. thanks for the breakdown, and I understand your point now. I considered a number of things, such as allowing a client to point to two lists (the best of both worlds). In the end, I didn't put it in (not that it's a done or baked idea). Your idea above could be similar, and its a good point that either E could return A and B, or E could actually do the aggregation themselves and return A|B directly. -- Wes Hardaker USC/ISI From nobody Wed Oct 2 12:15:03 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 D82F8120838 for ; Wed, 2 Oct 2019 01:13:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ShGmDYuoiX1O for ; Wed, 2 Oct 2019 01:13:05 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750071.outbound.protection.outlook.com [40.107.75.71]) (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 C428A120832 for ; Wed, 2 Oct 2019 01:13:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MtO01tmFzR++v1reNUFPdVSF7vNcAmgCcfMPCqQUBkTUzzZAuUZJUR1+YzlBNLk3ewMr2i6k5h6mXy6GbLjU4qtARsTBtztBiHmQgsJk1cpt+TiSQ1GB3fRVkfwQgvlOAdrPowgkhuG8D+Fy5P9BwnQX0dsXm0k+zelg8/8z79QRZlbs26FAJKFpH3gjlVZoHHudGcacDeAD55YUW2VRhRZkWuexx0CNe7dlDtC1JgA0+UHhjg292hzWbIYCK6aBkXj+npRN8MrRhR+Eii0AX63IeqQ6elEKmYBIA8i0v3ifUKkOKw4lPJ1jhWiLNu1he8QoKKjlgebrmmZLR5DWAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AfOarzxzzWHR6FINrK6CejNirKIgyKAOMO7Etg7Ikt4=; b=niGKUZlqX3yR24beBGN3qcaQwZfeabSlj7NeOEBy4qTo91tjyFRYamsAqPQUCJ4K9oprCsc7K819SCNH4HXsKvw+SO9rt1EHq9FHONY/U/rrhQO18GFLwD6FCQeMybm2Yt3O8nr6peQ6Z5vmixrmPkjzLf4CFkGvwIpDAK9E4hyq2DNMAkeLjjhD+KXfs0nm3lVyfOHyGoWxOVaJx5hStnkvcy3xIq2I6Pr1Ix63zh21ATpyC7oIwPVq1Nd42kTuwe8Dci0XhYa87Bv+HokgbI8CNoWWncUf0GYb+SrDowJ2v8pLMgNWjT73dWsIdxDYDKQbx5oUJqMTaLbWf/mqHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AfOarzxzzWHR6FINrK6CejNirKIgyKAOMO7Etg7Ikt4=; b=XPsaxF48i3Qr7aa7ELOU+cuFUYOCPM10Aw79oU0Z/hfkCom8Pb0rfZm0wLKbwAi4T5JjL5Csfg+m1gxMJpZattQl12wDJNxT3/xXXmwdQocTOGOgJfoYB002dNDTnKG9k5SbvTfRYiPsU3EHTG4qDMCfLHt4F1vsZ80Slqp4XJk= Received: from BN6PR06MB3300.namprd06.prod.outlook.com (10.174.234.151) by BN6PR06MB2739.namprd06.prod.outlook.com (10.173.143.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Wed, 2 Oct 2019 08:13:00 +0000 Received: from BN6PR06MB3300.namprd06.prod.outlook.com ([fe80::201f:6ad4:4aa9:37cc]) by BN6PR06MB3300.namprd06.prod.outlook.com ([fe80::201f:6ad4:4aa9:37cc%3]) with mapi id 15.20.2305.023; Wed, 2 Oct 2019 08:13:00 +0000 From: Mat Ford To: Wes Hardaker CC: ADD Mailing list Thread-Topic: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request Thread-Index: AQHVePk0b7usggRqREqR1VDToIqBWg== Date: Wed, 2 Oct 2019 08:13:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0232.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::28) To BN6PR06MB3300.namprd06.prod.outlook.com (2603:10b6:405:45::23) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ford@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Apple Mail (2.3594.4.18) x-originating-ip: [2001:8b0:dcb:7d85:bce4:d33e:ac67:e6b6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71a721ad-a874-43c9-6e6f-08d747105727 x-ms-traffictypediagnostic: BN6PR06MB2739: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39850400004)(346002)(136003)(366004)(376002)(51914003)(189003)(199004)(81156014)(229853002)(6486002)(14454004)(6116002)(36756003)(6512007)(478600001)(25786009)(71190400001)(316002)(6916009)(966005)(486006)(71200400001)(7736002)(6246003)(305945005)(4326008)(4744005)(5660300002)(11346002)(33656002)(86362001)(50226002)(186003)(256004)(8936002)(476003)(81166006)(8676002)(66476007)(66446008)(66946007)(2616005)(52116002)(6306002)(6436002)(14444005)(2906002)(76176011)(6506007)(386003)(102836004)(53546011)(561944003)(99286004)(46003)(64756008)(446003)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB2739; H:BN6PR06MB3300.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VYIV56ZlVq0iE/YhM8Yb/uPXv+M//6K7ZR+2ZAa5gHBzzXCxXOX2l2X2B07+WRhzFkjE8qdINewob3NBHFPHNPRpmL2IKKFu3JdDBiLRTcXqmDQ6jj+T4upDJeef/GfKwYKLmOjSs/wLzaKv6dPmdeDWNR5kMXIQixa99xeXV6Gln81HVx+l6tW2rfVUXd5SZTCXiMp6kTBpZP5TL3Aq2SeENh4vTGf3ozBFNaAGnpoxrunnTBIfvQlULZ1qAvkXN1HH4frBTRoorvPeq337tO0Am9N0yqj4moY1TKBkC3J7l7g+iaYd0gaIT9eLlMlARhS3H1S6Y93uBQ0ZKlNwybXk2pBrea0Lwe3Rz34aRuQg/rPWhPQF9Q2PCItuQfp6Tc3wI8tWWLkt7z2h4x8xQoQ36+YhcrQSfQRUS0v+S+P8lot4oIYNYcftFSSxJ8MC6lUg38KhYsNDbK4vOOlb6g== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 71a721ad-a874-43c9-6e6f-08d747105727 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 08:13:00.5744 (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-CrossTenant-userprincipalname: YnsTB98k0PsTQLhbBvwnCIfUHGJ4nMXcmMIn7IQ7PsWzpxxDEh5Asot1dVV/DVgT X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2739 Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:15:03 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 02 Oct 2019 08:13:07 -0000 Wes, > On 27 Sep 2019, at 22:12, Wes Hardaker wrote: >=20 >=20 > I spent some time trying to see what else we could do to better support > all parties in an ADD world. I wrote up the following in an effort to > spur thinking in new directions. You'll probably hate it :-) >=20 > https://datatracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-filt= er-request/ >=20 Thanks for the thought-provoking proposal Wes. Is the expectation here that= recursive resolvers would keep per-client state on which filter lists appl= y, and then check those filters against each query from the given client? D= o we know that this can be done scalably and quickly? As a naiive non-imple= menter of recursive resolvers this sounds like a performance and scalabilit= y nightmare to me. Mat= From nobody Wed Oct 2 12:15: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 6773C120045 for ; Wed, 2 Oct 2019 05:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 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, FROM_WORDY=2.354, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 CUTqQPO6N3Ww for ; Wed, 2 Oct 2019 05:31:25 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 D775812000F for ; Wed, 2 Oct 2019 05:31:24 -0700 (PDT) Date: Wed, 02 Oct 2019 12:31:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1570019481; bh=v/6Ll+dmoKDCMpI9ASepXMua/0L3Iw65YSj3AtpfeE0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=XbXQ3eZuBtoE18jLhahEhfy+QBHJ4BoOwQ0XSqzwKBDIVOVA9UiUZAia5aoJcGLLR A9lucg+rW1lBeOBQiIXvBNykzsk39JHWHU190KU5h70ans70hz1F90yaa8egckDIWf 2Zp00ZB8wW9BsMFo4M0KBqmULsq/F5j/lPCc8fZk= To: Vittorio Bertola From: "Arnaud.Taddei.IETF" Cc: Wes Hardaker , ADD Mailing list Reply-To: "Arnaud.Taddei.IETF" Message-ID: In-Reply-To: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> Feedback-ID: kou6vaSHQeY5dgFN9dCIYKo4z6hnnNmKuV4IBJw2wx4vSVPtftyhWUTBigri6zMJ3K1hxYJjI-3RAIGaizMt5g==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:15:21 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 02 Oct 2019 12:31:27 -0000 Wes, on the same line as Vittorio, thank you for daring to put this proposi= tion. It would actually fix many other things and this is really worth expl= oring further, this is encouraging. Agreed that we still have a massive issue as to how users can operate on su= ch capabilities but I think this is part of a much much bigger UX issue and= Human Factor issue and we are not going to resolve that now. Therefore your proposition is increasing the flexibility criteria of the po= tential future design. It is actually helping breaking the chicken and egg = situation in which we are. Keep doing Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday 30 September 2019 13:34, Vittorio Bertola wrote: > > Il 27 settembre 2019 23:12 Wes Hardaker wjhns1@hardakers.net ha scritto= : > > I spent some time trying to see what else we could do to better support > > all parties in an ADD world. I wrote up the following in an effort to > > spur thinking in new directions. You'll probably hate it :-) > > https://datatracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-fi= lter-request/ > > Thanks for daring to do this :-) > > My feeling is also that standardization work in the field of expressing, = communicating and implementing DNS filtering lists would help many use case= s (by the way, there already is a de-facto standard for a good part of this= , i.e. RPZ, so it should be part of the picture). However, we also know tha= t some people here believe that DNS filtering is always wrong, even when re= quested by the user. We could still have a standard for those that want to = use it, though. > > Also, you'd possibly need to flesh out a relatively complex architecture.= For example, there are cases in which the compiler of the filtering list d= oes not want to make it accessible to everyone, and there could be attacks = based on forging/spoofing legitimate lists, so you would want to have authe= ntication, channel security and access control. > > Then, there is the issue of which filters should be applied, which is a p= olicy and regulatory one; resolver operators could honor the user's request= for a given filter, but at the same time they might want to do their own m= alware filtering on top of it, or they might be required by law to block ye= t other stuff. So the communication of active filtering frameworks could go= in both directions. > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -------------------------------------------------------------------------= --------------------------------------------------------------------- > > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Wed Oct 2 12:16: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 4FDB5120019 for ; Wed, 2 Oct 2019 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 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, FROM_WORDY=2.354, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 9vgYPHKDIOJ8 for ; Wed, 2 Oct 2019 05:45:43 -0700 (PDT) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 B72A812000F for ; Wed, 2 Oct 2019 05:45:42 -0700 (PDT) Date: Wed, 02 Oct 2019 12:45:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1570020340; bh=KbOsV2UCBZRpKtshYV60yJpA17qQ+mKOSxoADUdPpCE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Y6Pl4GoJ2jrX8NVqnRSLmC+bKyTmFMhvOUh/dcc+2scj8rT1F/odCO1Ur8JZyHUgM MUzFyZ3fy/oxjSWPyqvqqp/HqlTfnRu5sw0iGBK0iG1ggrbU7A/FdtyklJ6EMu8UBA bI2BofZO/smm9imkV3wGepF0oGTYfRky/JVAkI08= To: Rob Sayre From: "Arnaud.Taddei.IETF" Cc: ADD Mailing list Reply-To: "Arnaud.Taddei.IETF" Message-ID: In-Reply-To: References: Feedback-ID: kou6vaSHQeY5dgFN9dCIYKo4z6hnnNmKuV4IBJw2wx4vSVPtftyhWUTBigri6zMJ3K1hxYJjI-3RAIGaizMt5g==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_292c5fe2c1b90c7b3742422c1e91ee23" Archived-At: X-Mailman-Approved-At: Wed, 02 Oct 2019 12:16:12 -0700 Subject: Re: [Add] NIST: Zero Trust Architecture 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, 02 Oct 2019 12:45:45 -0000 This is a multi-part message in MIME format. --b1_292c5fe2c1b90c7b3742422c1e91ee23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gdGhhdCBsaW5lIEkgaGVscGVkIFRlbmNlbnQgdG8gZXN0YWJsaXNoIGEgbmV3IHdvcmsgaXRl bSBYLnJmLWNzYXAgIlJlZmVyZW5jZSBmcmFtZXdvcmsgZm9yIGNvbnRpbnVvdXMgcHJvdGVjdGlv biBvZiBzZXJ2aWNlIGFjY2VzcyBwcm9jZXNzIiBpbiBJVFUtVCBRMi8xNyBhdCB0aGUgbGFzdCBT RzE3IG1lZXRpbmcgaW4gZWFybHkgc2VwdGVtYmVyLiBCZXlvbmQgdGhlIHRpdGxlIGl0IGlzIGFi b3V0IFpUQS4KClNlbnQgd2l0aCBbUHJvdG9uTWFpbF0oaHR0cHM6Ly9wcm90b25tYWlsLmNvbSkg U2VjdXJlIEVtYWlsLgoK4oCQ4oCQ4oCQ4oCQ4oCQ4oCQ4oCQIE9yaWdpbmFsIE1lc3NhZ2Ug4oCQ 4oCQ4oCQ4oCQ4oCQ4oCQ4oCQCk9uIFN1bmRheSAyOSBTZXB0ZW1iZXIgMjAxOSAxMTozMywgUm9i IFNheXJlIDxzYXlyZXJAZ21haWwuY29tPiB3cm90ZToKCj4gSGksCj4KPiBJJ3ZlIGZvdW5kIGEg Y291cGxlIHJlZmVyZW5jZXMgY29uY2VybmluZyAiWmVybyBUcnVzdCBBcmNoaXRlY3R1cmUiIHRo YXQgc2VlbSByZWxldmFudCB0byB0aGUgbGV2ZWwgb2YgdHJ1c3QgY2xpZW50cyBhbmQgc2VydmVy cyBtaWdodCBnaXZlIHRvIGludGVybWVkaWFyaWVzLiBUaGVyZSdzIHRoaXMgb25lIGZyb20gTklT VCwgd2hpY2ggSSB0aGluayB3YXMgcHVibGlzaGVkIGFib3V0IDUgZGF5cyBhZ286Cj4KPiAiWlRB IGZvY3VzZXMgb24gcHJvdGVjdGluZyByZXNvdXJjZXMsIG5vdCBuZXR3b3JrIHNlZ21lbnRzLCBh cyB0aGUgbmV0d29yayBsb2NhdGlvbiBpcyBubyBsb25nZXIgc2VlbiBhcyB0aGUgcHJpbWUgY29t cG9uZW50IHRvIHRoZSBzZWN1cml0eSBwb3N0dXJlIG9mIHRoZSByZXNvdXJjZS4iCj4gaHR0cHM6 Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9kZXRhaWwvc3AvODAwLTIwNy9kcmFmdAo+Cj4g T25lIHByb21pbmVudCBleGFtcGxlIG9mIHRoaXMgYXJjaGl0ZWN0dXJlIGlzIEdvb2dsZSdzIEJl eW9uZENvcnA6Cj4gaHR0cHM6Ly93d3cuYmV5b25kY29ycC5jb20vCj4KPiBJIGFsc28gZm91bmQg c29tZSByZWxhdGVkIGVhcmxpZXIgZGViYXRlIG9uIHRoZSBUTFMgRVNOSSBleHRlbnNpb24uIFRo aXMgdGhyZWFkIHNlZW1zIHNpbWlsYXIgdG8gc29tZSB0aHJlYWRzIG9uIHRoaXMgbGlzdDoKPiBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Rscy9Mb0JTbDM2eXRaaHUwVHV4 TGZJeURHblQ5MlEKPgo+IHRoYW5rcywKPiBSb2I= --b1_292c5fe2c1b90c7b3742422c1e91ee23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLCBzYW5zLXNlcmlmOyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTRweCI+T24gdGhhdCBsaW5lIEkgaGVscGVkIFRlbmNlbnQgdG8g ZXN0YWJsaXNoIGEgbmV3IHdvcmsgaXRlbSBYLnJmLWNzYXAgIjwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwgMjU1LCAyNTUpIj48c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDM0LCAzNCwgMzQpIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsLCBz YW5zLXNlcmlmOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTRweCI+UmVmZXJlbmNlIGZyYW1l d29yayBmb3IgY29udGludW91cyBwcm90ZWN0aW9uIG9mIHNlcnZpY2UgYWNjZXNzIHByb2Nlc3Mi IGluIElUVS1UIFEyLzE3IGF0IHRoZSBsYXN0IFNHMTcgbWVldGluZyBpbiBlYXJseSBzZXB0ZW1i ZXIuIEJleW9uZCB0aGUgdGl0bGUgaXQgaXMgYWJvdXQgWlRBLjwvc3Bhbj48L3NwYW4+PC9zcGFu Pjwvc3Bhbj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9z aWduYXR1cmVfYmxvY2siPjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXVz ZXIgcHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiPjxicj48L2Rpdj48ZGl2IGNsYXNz PSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1wcm90b24iPlNlbnQgd2l0aCA8YSBocmVmPSJo dHRwczovL3Byb3Rvbm1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+UHJvdG9uTWFpbDwvYT4gU2Vj dXJlIEVtYWlsLjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PuKAkOKAkOKAkOKA kOKAkOKAkOKAkCBPcmlnaW5hbCBNZXNzYWdlIOKAkOKAkOKAkOKAkOKAkOKAkOKAkDxicj48L2Rp dj48ZGl2PiBPbiBTdW5kYXkgMjkgU2VwdGVtYmVyIDIwMTkgMTE6MzMsIFJvYiBTYXlyZSAmbHQ7 c2F5cmVyQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJyPjwvZGl2PjxkaXY+IDxicj48L2Rpdj48Ymxv Y2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlwZT0iY2l0ZSI+PGRpdiBkaXI9Imx0 ciI+PGRpdj5IaSw8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JJ3ZlIGZvdW5kIGEgY291 cGxlIHJlZmVyZW5jZXMgY29uY2VybmluZyAiWmVybyBUcnVzdCBBcmNoaXRlY3R1cmUiIHRoYXQg c2VlbSByZWxldmFudCB0byB0aGUgbGV2ZWwgb2YgdHJ1c3QgY2xpZW50cyBhbmQgc2VydmVycyBt aWdodCBnaXZlIHRvIGludGVybWVkaWFyaWVzLiBUaGVyZSdzIHRoaXMgb25lIGZyb20gTklTVCwg d2hpY2ggSSB0aGluayB3YXMgcHVibGlzaGVkIGFib3V0IDUgZGF5cyBhZ286PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+IlpUQSBmb2N1c2VzIG9uIHByb3RlY3RpbmcgcmVzb3VyY2VzLCBu b3QgbmV0d29yayBzZWdtZW50cywgYXMgdGhlIG5ldHdvcmsgbG9jYXRpb24gaXMgbm8gbG9uZ2Vy IHNlZW4gYXMgdGhlIHByaW1lIGNvbXBvbmVudCB0byB0aGUgc2VjdXJpdHkgcG9zdHVyZSBvZiB0 aGUgcmVzb3VyY2UuIjxicj48L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vY3NyYy5uaXN0Lmdv di9wdWJsaWNhdGlvbnMvZGV0YWlsL3NwLzgwMC0yMDcvZHJhZnQiPmh0dHBzOi8vY3NyYy5uaXN0 Lmdvdi9wdWJsaWNhdGlvbnMvZGV0YWlsL3NwLzgwMC0yMDcvZHJhZnQ8L2E+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+T25lIHByb21pbmVudCBleGFtcGxlIG9mIHRoaXMgYXJjaGl0ZWN0 dXJlIGlzIEdvb2dsZSdzIEJleW9uZENvcnA6PGJyPjwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuYmV5b25kY29ycC5jb20vIj5odHRwczovL3d3dy5iZXlvbmRjb3JwLmNvbS88L2E+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBhbHNvIGZvdW5kIHNvbWUgcmVsYXRlZCBlYXJs aWVyIGRlYmF0ZSBvbiB0aGUgVExTIEVTTkkgZXh0ZW5zaW9uLiBUaGlzIHRocmVhZCBzZWVtcyBz aW1pbGFyIHRvIHNvbWUgdGhyZWFkcyBvbiB0aGlzIGxpc3Q6PGJyPjwvZGl2PjxkaXY+PGEgaHJl Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90bHMvTG9CU2wzNnl0Wmh1 MFR1eExmSXlER25UOTJRIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Rs cy9Mb0JTbDM2eXRaaHUwVHV4TGZJeURHblQ5MlE8L2E+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+dGhhbmtzLDxicj48L2Rpdj48ZGl2PlJvYjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj48YnI+PC9kaXY+ --b1_292c5fe2c1b90c7b3742422c1e91ee23-- From nobody Thu Oct 3 08:35: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 2266B12007A for ; Wed, 2 Oct 2019 19:28:38 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Qvkykq+s; dkim=pass (1536-bit key) header.d=taugh.com header.b=Bn2w9ENU 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 M6B62CdQhBnp for ; Wed, 2 Oct 2019 19:28:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F295C120073 for ; Wed, 2 Oct 2019 19:28:35 -0700 (PDT) Received: (qmail 28297 invoked from network); 3 Oct 2019 02:28:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=6e87.5d955cd2.k1910; i=johnl-iecc.com@submit.iecc.com; bh=wmQNIgwvZx0dsBrZmsPTGchU19UR8QdRV9JfWF24sTc=; b=Qvkykq+sp1nQgrwri1wse0Y6qSlD24PB2XbpmGtULo1sc2Jdf4Jg4iIm/G3D5X9KB0MVIFV0jXUI9FmRgfOML3RiKLTwZeKJY/rpptdUOcOn7+84MeHKHu8V6jsGjwcIRd0vatatfhreTQe1QlZaODu1wREzY5DdLf3taG+7KHB/jjMQF+3yXXVhAJfsJ5ziOueKQHEovK8OXTZLxVChKakqBUr10FRdvLsF5xGE9OGgXpGDISrsJXDU7tRnSIc8 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=6e87.5d955cd2.k1910; olt=johnl-iecc.com@submit.iecc.com; bh=wmQNIgwvZx0dsBrZmsPTGchU19UR8QdRV9JfWF24sTc=; b=Bn2w9ENU3tjVciTVIQF7tVCqQkuWOuVc8y9iwOvvpJTBhEtCUqBRPzqPL37TqBjjbyVBjLwBWcECBkbiL/n8m9SrLtgxbm8PYK23/yjI2lg0wL3qt1gCpM4K8ZE05nfm0O8GH7ut9x9wmLz/rMDtcFDD4DZ4hkdCfLrKGWwaJtuL+I7UcV3ipr6+jYZ1nsbHgJOQrbaeQNrgDRpf03f5cfBn0AOw5gjNK6oOu26gx+qNHKYC8AJ4Diw11QaAsSUd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 03 Oct 2019 02:28:34 -0000 Date: 2 Oct 2019 22:28:33 -0400 Message-ID: From: "John R Levine" To: add@ietf.org User-Agent: Alpine 2.21.99999 (OSX 368 2019-09-06) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-Mailman-Approved-At: Thu, 03 Oct 2019 08:35:35 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 03 Oct 2019 02:28:38 -0000 >> If it were me, I'd say you get what you get, and if you want something >> else, use 8.8.8.8 or someone with the same taste in filtering you >> have. > > And that's one option. However, that forces resolvers to become good > filterers or filter experts to become good world-class resolvers. Either that or outsource it. It's moving in the direction that e-mail is. When I'm on public networks these days at hotels and airports, as often as not the DNS resolver I get from DHCP is 8.8.8.8. If you want to run your servers yourself, for mail systems there's a lot of external info available to run your spam filters, like DNSBLs of IP addresses and domain names, and spammy patterns to update your spamassassin, that we use along with local tweaks. I expect that DNS resolvers will similarly use advice from external sources, probably distributed as RPZ, again with local tweaks. It also occurs to me that it'd be pretty painful to have one resolver trying to mix and match filter policies, so if you did this, it'd make more sense for the initial query to send back an IP address and port of the resolver that provides that policy. Maybe it'd be local, maybe it'd point somewhere else. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Oct 3 08:36:05 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 6A77C120043 for ; Wed, 2 Oct 2019 14:53: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_HELO_NONE=0.001, 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 uVLgLFkD-o8e for ; Wed, 2 Oct 2019 14:53: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 D0BA312002F for ; Wed, 2 Oct 2019 14:53:26 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 109742A041; Wed, 2 Oct 2019 14:53:22 -0700 (PDT) From: Wes Hardaker To: Mat Ford Cc: Wes Hardaker , ADD Mailing list References: Date: Wed, 02 Oct 2019 14:53:21 -0700 In-Reply-To: (Mat Ford's message of "Wed, 2 Oct 2019 08:13:00 +0000") 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: X-Mailman-Approved-At: Thu, 03 Oct 2019 08:36:04 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 02 Oct 2019 21:53:28 -0000 Mat Ford writes: > > I spent some time trying to see what else we could do to better support > > all parties in an ADD world. I wrote up the following in an effort to > > spur thinking in new directions. You'll probably hate it :-) > > > > https://datatracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-filter-request/ > > > > Thanks for the thought-provoking proposal Wes. Is the expectation here > that recursive resolvers would keep per-client state on which filter > lists apply, and then check those filters against each query from the > given client? Do we know that this can be done scalably and quickly? > As a naiive non-implementer of recursive resolvers this sounds like a > performance and scalability nightmare to me. There are certainly synchronization issues to work out, and as I mentioned in another thread, RBL might be a better solution but requires more at-the-time round trips. -- Wes Hardaker USC/ISI From nobody Thu Oct 3 08:36: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 981A712006F for ; Wed, 2 Oct 2019 14:57:32 -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_HELO_NONE=0.001, 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 jzfwoIz-0TFV for ; Wed, 2 Oct 2019 14:57:31 -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 33A8012006E for ; Wed, 2 Oct 2019 14:57:31 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id B19C72A041; Wed, 2 Oct 2019 14:57:30 -0700 (PDT) From: Wes Hardaker To: "John Levine" Cc: add@ietf.org References: <20191001175427.3B038B790C8@ary.qy> Date: Wed, 02 Oct 2019 14:57:30 -0700 In-Reply-To: <20191001175427.3B038B790C8@ary.qy> (John Levine's message of "1 Oct 2019 13:54:26 -0400") 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: X-Mailman-Approved-At: Thu, 03 Oct 2019 08:36:03 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 02 Oct 2019 21:57:33 -0000 "John Levine" writes: > If it were me, I'd say you get what you get, and if you want something > else, use 8.8.8.8 or someone with the same taste in filtering you > have. And that's one option. However, that forces resolvers to become good filterers or filter experts to become good world-class resolvers. > Also, as has been noted once or twice before, a lot of DNS filtering > is policy based, and the provider has no interest in making it easy > to substitute someone else's policy for its own. That certainly may be true. And certainly if there seems to be a market for user-specified policies, but a resolver implementation says "nope, our policy only", then that will be an interesting signal about their intentions. -- Wes Hardaker USC/ISI From nobody Thu Oct 3 08:36: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 72FAB1200FF for ; Wed, 2 Oct 2019 17:01:54 -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_HELO_NONE=0.001, 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 PBnpnkCuklB5 for ; Wed, 2 Oct 2019 17:01:52 -0700 (PDT) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DE21200F4 for ; Wed, 2 Oct 2019 17:01:52 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9E3F73256A; Wed, 2 Oct 2019 20:01:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23957.14959.623208.660312@gro.dd.org> Date: Wed, 2 Oct 2019 20:01:51 -0400 From: Dave Lawrence To: ADD Mailing list In-Reply-To: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> Archived-At: X-Mailman-Approved-At: Thu, 03 Oct 2019 08:36:45 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 03 Oct 2019 00:01:55 -0000 Vittorio Bertola writes: > However, we also know that some people here believe that DNS > filtering is always wrong, even when requested by the user. Any chance you remember enough about those messages to point to them in the list archive? It's such a remarkable position to take, the "even when requested by the user" part, that I'm surprised I don't remember them. From nobody Thu Oct 3 08: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 E23C01200FF for ; Wed, 2 Oct 2019 17:14:29 -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_HELO_NONE=0.001, 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 mSUCHrBqn5I5 for ; Wed, 2 Oct 2019 17:14:29 -0700 (PDT) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD721200F4 for ; Wed, 2 Oct 2019 17:14:28 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id C30A232575; Wed, 2 Oct 2019 20:14:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23957.15715.773286.735999@gro.dd.org> Date: Wed, 2 Oct 2019 20:14:27 -0400 From: Dave Lawrence To: ADD Mailing list In-Reply-To: References: <20190928153534.B6A7317C8725@fafnir.remote.dragon.net> Archived-At: X-Mailman-Approved-At: Thu, 03 Oct 2019 08:36:45 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 03 Oct 2019 00:14:30 -0000 Wes Hardaker writes: > I actually think that it's more likely users will get their policy > bundled with some other software. IE, they install an anti-virus > package and one of the things it does is configure the local OS policy > to request the anti-virus black list in outgoing DNS requests. What do you see as the difference vs the anti-virus software just setting up the hooks for the device doing the filtering itself on the DNS responses? Sure, it can't see into an encrypted DNS request stream from an application doing its own DNS, but it seems to me (perhaps without enough vision, I realize) that how that's dealt with is pretty much the same as determining whether those encrypting applications are using the request-to-filter option with the external resolver. Basically I'm not really getting how pushing the implementation requirement out to the external resolver improves things. From nobody Fri Oct 4 08:05: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 825A21208A4 for ; Thu, 3 Oct 2019 16:17:09 -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_HELO_NONE=0.001, 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 YJM6HxHFZKcl for ; Thu, 3 Oct 2019 16:17:07 -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 7FF131208FA for ; Thu, 3 Oct 2019 16:17:07 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 986302A243; Thu, 3 Oct 2019 16:17:03 -0700 (PDT) From: Wes Hardaker To: Dave Lawrence Cc: ADD Mailing list References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> Date: Thu, 03 Oct 2019 16:17:03 -0700 In-Reply-To: <23957.14959.623208.660312@gro.dd.org> (Dave Lawrence's message of "Wed, 2 Oct 2019 20:01:51 -0400") 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: X-Mailman-Approved-At: Fri, 04 Oct 2019 08:05:42 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 03 Oct 2019 23:17:10 -0000 Dave Lawrence writes: > Vittorio Bertola writes: > > However, we also know that some people here believe that DNS > > filtering is always wrong, even when requested by the user. >=20 > Any chance you remember enough about those messages to point to them > in the list archive? It's such a remarkable position to take, the > "even when requested by the user" part, that I'm surprised I don't > remember them. You're right that my statement was probably a bit extreme. But taking it up a bit higher, we know that the point of DoH is to bypass filtering, rewriting, firewalling and snooping in general. If we weren't worried about firewalling, DoT would be sufficient. If we weren't worried about firewalling and snooping, DNSSEC would be sufficient. I think there is a high level of variation between what open resolvers might filter, based on marketing needs, legal needs, etc. In general, I think the diversity is probably a good thing, but it does make it harder for users to control. If a resolver wants to optimize for speed, they probably want to do less filtering. If they want to offer filtering as a service, they may not optimize for speed as much. I doubt anyone, to correct my previous statement, is fully at either end of that spectrum. But it seems that there is a diverse set of opinions about where the right spot on that spectrum is. Two examples might include google and opendns: >From the google FAQ: Does Google Public DNS offer the ability to block or filter out unwanted sites?=EF=BF=BC No. Google Public DNS is purely a DNS resolution and caching server; it does not perform any blocking or filtering of any kind, except that it may not resolve certain domains in extraordinary cases if we believe this is necessary to protect Google=E2=80=99s users from securi= ty threats. But we believe that blocking functionality is usually best performed by the client. If you are interested in enabling such functionality, you should consider installing a client-side application or browser add-on for this purpose. OpenDNS is rather flexible and offers a 4 filtering options (I think) to pick from for filtering, and more customization if you want it. OpenDNS solutions such as FamilyShield use preconfigured Web content filtering and blocking that is not adjustable. OpenDNS=E2=80=99s preconfigured solutions provide easy-to-implement protection for networks where manual configuration is not desired. To use a preconfigured OpenDNS solution, set your DNS parameters to the appropriate IP address. But their priorities are clearly different, and studying things like their speed or effectiveness at blocking what you don't like will clearly get different results. As an example of the speed differences, I believe they have been studied extensively. Here's a random duck-duck-go search result: https://hackernoon.com/dns-performance-comparison-google-quad9-opendns-nort= on-cleanbrowsing-and-yandex-d62d24e38f98 --=20 Wes Hardaker USC/ISI From nobody Fri Oct 4 08:05: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 55AB712095C for ; Thu, 3 Oct 2019 16:21:23 -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_HELO_NONE=0.001, 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 cvRpbfs5HfGA for ; Thu, 3 Oct 2019 16:21:21 -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 D446E120937 for ; Thu, 3 Oct 2019 16:21:21 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 5306920EF4; Thu, 3 Oct 2019 16:21:21 -0700 (PDT) From: Wes Hardaker To: Dave Lawrence Cc: ADD Mailing list References: <20190928153534.B6A7317C8725@fafnir.remote.dragon.net> <23957.15715.773286.735999@gro.dd.org> Date: Thu, 03 Oct 2019 16:21:21 -0700 In-Reply-To: <23957.15715.773286.735999@gro.dd.org> (Dave Lawrence's message of "Wed, 2 Oct 2019 20:14:27 -0400") 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: X-Mailman-Approved-At: Fri, 04 Oct 2019 08:05:42 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 03 Oct 2019 23:21:28 -0000 Dave Lawrence writes: > Wes Hardaker writes: > > I actually think that it's more likely users will get their policy > > bundled with some other software. IE, they install an anti-virus > > package and one of the things it does is configure the local OS policy > > to request the anti-virus black list in outgoing DNS requests. > Your good question is below. That being said, reminder that the point of the draft was somewhat of a thought experiment... > What do you see as the difference vs the anti-virus software just > setting up the hooks for the device doing the filtering itself on the > DNS responses? I think there would some end-user complexity reduction in needing to synchronize filtering, for example. (Though users must do this now for virus/malware detection of course). I think that a resolver/filtering combination would likely promote happier eyeballs as the filtering will likely much more efficient generically and through the use of shared response caching potentially. -- Wes Hardaker USC/ISI From nobody Fri Oct 4 08:06:15 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 2D7D31207FD for ; Fri, 4 Oct 2019 01:09:55 -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_HELO_NONE=0.001, 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 jXjF5HubUD70 for ; Fri, 4 Oct 2019 01:09:53 -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 505A1120018 for ; Fri, 4 Oct 2019 01:09:53 -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 8235D6A277; Fri, 4 Oct 2019 10:09:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570176591; bh=7q8n6d9r/wmcTiLa02STPq7xPuLNkz73OV3pNhMNc1E=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=9uV14+QMj+JBxnZjm2hBvlLk23Mqj9u7ZXl5BaQJKcqMHFXeFbANXRV3HARJvtMIc losJQwrhexsHg3XyAX1HXFJZ9ijV2ohKzCo5uUu/P39IbAhYNKdg0M8aARdwa4FKx7 3sgjrf7uzOV72KbfjOOLMdTdQp7Fuzys3vcbU322HQP4dQ3UybYWolDZMZfvfxiCZx UnrgyN9Y/ajFHDXvjkj4xhWVJ+z5qO4y8Y+HxL77Wu2HTt0u4RIGO0tE52MytxunUc sfZl6c7ZITUHoSfiTnIfhIX9rZw4J2HROFDft11RqpyVqrK/fM1/DzzgQgHomDRELa rKVuHzyGGmOuA== 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 749E03C0311; Fri, 4 Oct 2019 10:09:51 +0200 (CEST) Date: Fri, 4 Oct 2019 10:09:51 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Dave Lawrence , ADD Mailing list Message-ID: <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> In-Reply-To: <23957.14959.623208.660312@gro.dd.org> References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: X-Mailman-Approved-At: Fri, 04 Oct 2019 08:06:07 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 04 Oct 2019 08:09:55 -0000 > Il 3 ottobre 2019 02:01 Dave Lawrence ha scritto: > > Vittorio Bertola writes: > > However, we also know that some people here believe that DNS > > filtering is always wrong, even when requested by the user. > > Any chance you remember enough about those messages to point to them > in the list archive? It's such a remarkable position to take, the > "even when requested by the user" part, that I'm surprised I don't > remember them. Sure: just go to Mozilla's presentation from the BoF in Montreal ( https://datatracker.ietf.org/meeting/105/materials/slides-105-add-dns-in-applications-one-applications-perspective-00.pdf ) where they say that DNS was a control surface but is not any more, and that "in the long term" DNS filtering won't work and "entities looking to exert control will have to engage with owners of endsystems". During the presentation they also made clear that their canary domain detection mechanism is a short-term fix to give people some time to adapt, and will go away in the future. Of course, if you act to change things so that DNS-as-a-control-surface will stop working, it won't be possible to provide filtering even when the user actually wants it. But they are not the only ones with these views: I think Stephane Bortzmeyer shares them (but he can correct me if I'm wrong) and I received similar comments from a well-known digital rights coalition in Europe (not sure they are on this list though). These are respectable views and I do see the risk that once DNS filtering is technically possible it can be used to violate human rights, which could be considered as a sufficient motivation for making it "tout court" illegal or technically impossible. I just think that it also has lots of positive uses and so it is better to continue using it under appropriate rules, much like more or less any other technology. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sat Oct 5 08:41: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 ABB371208C4 for ; Fri, 4 Oct 2019 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxPNvWvvEXGq for ; Fri, 4 Oct 2019 08:30:52 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 C17EC120897 for ; Fri, 4 Oct 2019 08:30:51 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id c195so4775319lfg.9 for ; Fri, 04 Oct 2019 08:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DfdnWR84qv6Fgz2kvYDQkWJzlFOYOCxgeRMjo2C4ZLg=; b=VWCTxsYLoriyoDMWDLs9NSJRpBs0aGJTniy5tf8hV2rE/9+qv7l0Sud9/7YjxQsZln PKVZaZfysz6pe2jQNcAgTeKgUhu7w7zaJEY9/aq2+xbgPgq/IpIUfbjZBTJBVCrilV2u LsmYJ4bz4Uck6yVjMcFcM5fcqClwob2fiCW9a12nHgyX0d8D6M+sA14Kj7ebmopN80Rj i2NYgZ7Wx4V0rzgjmHKHZaPz5X0rGX+krp7cCtshUzFitm/l34HIzYTyaTxXHaSIYlvE 7BNYaYU7vt/j2xVCbnz+dcTqQ4WkuIlgNaZOuAouwMOaT8Rxb2W7o2x/cv7HUhjTtual Ap3w== 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=DfdnWR84qv6Fgz2kvYDQkWJzlFOYOCxgeRMjo2C4ZLg=; b=Jv4acCB7xbOuT7aD48GZ9f3UD0CxQhd3U0NVcWvijLeyV7SM7cqZiGDdux/bmWcIq6 ZzUFh6aHhaWpZ6qXxIR3sQ6KhtkIsE7na6KOEmoQC7hRmrEGEFddQLYQ+QdqWmWSY3nh bjEDRnwbPVDW5+XcVtn+g9dmrXhhho53xbSNIPZ8AAlJKmr/QriG68X6wciexWMpqibX b4DAOQYoTJBLB7wz9haKs3eEZtWRTklZFIVJqbqzM8J8Rvq41kW0wpBjyQ6QZit+A2Ep TBlNa/HDOqljQ2/zY6DO0MLBSK5jZPNGpA7mvpxXbJUoiC6vtrMkLO0aGLdmGgQBM/QR jXdw== X-Gm-Message-State: APjAAAXzEcuytIp9r3yfCQWuXQmm5Lh9axtXNq197cHVjsEwWhSutjPU XLIzHjQ+RCQMw6CAQsAK+nYTYP85pNqLiUHH/HA/rf9SHjA= X-Google-Smtp-Source: APXvYqz2+B9GpKBo8+RLJFZJKfQMW3X/cJyGAym9Bx96c79zHeYKVnlEFg0VE76H7MQoF0eXvOQgR/CX3+EoKpQDZ70= X-Received: by 2002:a19:c80b:: with SMTP id y11mr9828890lff.184.1570203049981; Fri, 04 Oct 2019 08:30:49 -0700 (PDT) MIME-Version: 1.0 References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> In-Reply-To: <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> From: Eric Rescorla Date: Fri, 4 Oct 2019 08:30:13 -0700 Message-ID: To: Vittorio Bertola Cc: Dave Lawrence , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000050e42059417639b" Archived-At: X-Mailman-Approved-At: Sat, 05 Oct 2019 08:41:43 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 04 Oct 2019 15:30:55 -0000 --000000000000050e42059417639b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 4, 2019 at 8:06 AM Vittorio Bertola wrote: > > Il 3 ottobre 2019 02:01 Dave Lawrence ha scritto: > > > > Vittorio Bertola writes: > > > However, we also know that some people here believe that DNS > > > filtering is always wrong, even when requested by the user. > > > > Any chance you remember enough about those messages to point to them > > in the list archive? It's such a remarkable position to take, the > > "even when requested by the user" part, that I'm surprised I don't > > remember them. > > Sure: just go to Mozilla's presentation from the BoF in Montreal ( > https://datatracker.ietf.org/meeting/105/materials/slides-105-add-dns-in-= applications-one-applications-perspective-00.pdf > ) where they say that DNS was a control surface but is not any more, and > that "in the long term" DNS filtering won't work and "entities looking to > exert control will have to engage with owners of endsystems". During the > presentation they also made clear that their canary domain detection > mechanism is a short-term fix to give people some time to adapt, and will > go away in the future. Of course, if you act to change things so that > DNS-as-a-control-surface will stop working, it won't be possible to provi= de > filtering even when the user actually wants it. > One of the problems with attempting to paraphrase people's views is that you often don't do so accurately, and that seems to be the case here. Mozilla's position is not "that DNS filtering is always wrong, even when requested by the user". Martin laid out our thinking in some detail, but I'll try to summarize here. 1. In the long term, we do not believe that unilateral filtering by network entities is viable. Without some engagement/consent by the "owner of the endsystem" then filtering by parties which the owner might perceive as legitimate is indistinguishable from attack. 2. If the owner of the endsystem consents, then DNS filtering is a viable mechanism, though we don't think it's the best point to do filtering at, in part because the granularity of filtering is quite coarse (compare, for instance, Safe Browsing, which operates at a URL prefix level). However, that seems like a reasonable set of technological tradeoffs for people to make and Mozilla's TRR policies explicitly state that "Resolvers may block or filter content with the user=E2=80=99s explicit consent." 3. In the short term, we are aware that there is DNS filtering (principally parental controls) which is performed with user consent by non-TRR resolvers. To avoid breaking those environments, we have implemented a set of mechanism (principally the canary) to attempt to detect those cases and disable DoH. However, because this allows for active downgrade attack, we do not consider the canary mechanism viable in the long-term, and would expect to eventually require some engagement with the endsystem to disable DoH. -Ekr --000000000000050e42059417639b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 4, 2019 at 8:06 AM Vittor= io Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> wrote:
> Il 3 ottobre 2019 02:01 D= ave Lawrence <tale@dd.o= rg> ha scritto:
>=C2=A0
> Vittorio Bertola writes:
> > However, we also know that some people here believe that DNS
> > filtering is always wrong, even when requested by the user.
>
> Any chance you remember enough about those messages to point to them > in the list archive?=C2=A0 It's such a remarkable position to take= , the
> "even when requested by the user" part, that I'm surpris= ed I don't
> remember them.

Sure: just go to Mozilla's presentation from the BoF in Montreal ( https://datatracker.ietf.org/meeting/105/materials/slides-= 105-add-dns-in-applications-one-applications-perspective-00.pdf ) where= they say that DNS was a control surface but is not any more, and that &quo= t;in the long term" DNS filtering won't work and "entities lo= oking to exert control will have to engage with owners of endsystems".= During the presentation they also made clear that their canary domain dete= ction mechanism is a short-term fix to give people some time to adapt, and = will go away in the future. Of course, if you act to change things so that = DNS-as-a-control-surface will stop working, it won't be possible to pro= vide filtering even when the user actually wants it.
<= br>
One of the problems with attempting to paraphrase people'= s views is
that you often don't do so accurately, and that seems to = be the case
here.


Mozilla's position is not "that DN= S filtering is always wrong, even
when requested by the user". Mart= in laid out our thinking in some
detail, but I'll try to summarize h= ere.

1. In the long term, we do not believe that unilateral filterin= g by
network entities is viable. Without some engagement/consent by the<= br>"owner of the endsystem" then filtering by parties which the o= wner
might perceive as legitimate is indistinguishable from attack.
<= br>2. If the owner of the endsystem consents, then DNS filtering is a
vi= able mechanism, though we don't think it's the best point to do
= filtering at, in part because the granularity of filtering is quite
coar= se (compare, for instance, Safe Browsing, which operates at a URL
prefix= level). However, that seems like a reasonable set of
technological trad= eoffs for people to make and Mozilla's TRR policies
explicitly state= that "Resolvers may block or filter content with the
user=E2=80=99= s explicit consent."

3. In the short term, we are aware that th= ere is DNS filtering
(principally parental controls) which is performed = with user consent
by non-TRR resolvers. To avoid breaking those environm= ents, we have
implemented a set of mechanism (principally the canary) to= attempt to
detect those cases and disable DoH. However, because this al= lows for
active downgrade attack, we do not consider the canary mechanis= m
viable in the long-term, and would expect to eventually require
som= e engagement with the endsystem to disable DoH.

-Ekr
<= br>
--000000000000050e42059417639b-- From nobody Sat Oct 5 08:42: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 10290120103 for ; Fri, 4 Oct 2019 08:45:41 -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_HELO_NONE=0.001, 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 Few9j8WcVyVa for ; Fri, 4 Oct 2019 08:45:36 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 983B01208D9 for ; Fri, 4 Oct 2019 08:45:36 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 6CBCB5F42A11; Fri, 4 Oct 2019 17:45:35 +0200 (CEST) Received: from [172.19.152.101] (tmo-120-254.customers.d1-online.com [80.187.120.254]) (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 A822C5F40499; Fri, 4 Oct 2019 17:45:34 +0200 (CEST) From: "Ralf Weber" To: "Wes Hardaker" Cc: "ADD Mailing list" Date: Fri, 04 Oct 2019 17:45:33 +0200 X-Mailer: MailMate (1.13r5655) Message-ID: <8CAFDD97-43ED-4EA6-B820-F2510FBC5AD9@fl1ger.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sat, 05 Oct 2019 08:42:09 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 04 Oct 2019 15:45:41 -0000 Moin! On 27 Sep 2019, at 23:12, Wes Hardaker wrote: > I spent some time trying to see what else we could do to better support > all parties in an ADD world. I wrote up the following in an effort to > spur thinking in new directions. You'll probably hate it :-) Not sure I hate it. But having operated recursive services for large part of my professional life it certainly doesn’t make me cheer. Let me give you how I see that draft. So I’m as an recursive resolver operator shall give some random guy on the internet the power to define what I filter and I then have to filter this probably different for different users. I already thought of at least three attacks/denial of service scenarios while writing this: - App making browsing impossible by add . to the filter list - Creating millions of different blocking scenarios - Creating a huge list of blocked domains two and three could also strike as a combination and might not be attacks but normal usage instead. I also have some experience in using DNS for blocking and other policy use cases and I can tell you it is not uncommon for these list to be counted gigabytes in memory, and now have lots of them and different ones for different users is just something that will not fly or create huge complexity in lookup chains. DNS policy always has and has to be local. The resolver operator decides what to do based on his use cases. Letting someone else decide that is IMHO a bad idea. So long -Ralf —-- Ralf Weber From nobody Sat Oct 5 08:42: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 9A2DA120103 for ; Fri, 4 Oct 2019 09:11:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 6B8cyISPhzAX for ; Fri, 4 Oct 2019 09:11:09 -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 E2A5C120086 for ; Fri, 4 Oct 2019 09:11:08 -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 2E33C6A297; Fri, 4 Oct 2019 18:11:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570205467; bh=HSj3jAXNYnBROcf3BYakU+DQozq3tZhLxGaDr4Y2A5Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=xSSaI6LBVuvROVcqp8TrWKvUQaB0i6OF7oSNA0MHMVaTvMWBUbn+koUGXLfVlOx8+ cfSg7EvU26GLf+8TXSEP8Yfy4ECOQ9GuSZC0ib1WtVKH4BCIphQJWtgXba8Z2GNn/p 6FPr8tKnoiKMWIbbcSqoUbeNDmo0xFBjb/B5Sen7ll79TnDgS4gExArowqCWQAUJ7L Iz0A0wIR7kFBpHOaHSLsRvN4hG7Mro5jCLxTJK+Ru8Fzmeo9JiNlt9EjvSRjMkIdmi G2U/fITxTg3S7osgqqcyRMPx2ifzAbQYEhn08eeV3q1wdqoBnEzNrUsooedTws5FzP SRoYUZ9U+03kg== 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 21D963C0101; Fri, 4 Oct 2019 18:11:07 +0200 (CEST) Date: Fri, 4 Oct 2019 18:11:07 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Eric Rescorla Cc: ADD Mailing list Message-ID: <1428589845.15401.1570205467043@appsuite-gw2.open-xchange.com> In-Reply-To: References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: X-Mailman-Approved-At: Sat, 05 Oct 2019 08:42:35 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 04 Oct 2019 16:11:12 -0000 =20 =20

Il 4 ottobre 2019 17:30 Eric Rescorla <ekr@rtfm.com> ha scritto:

Mozilla's position is not "that DNS filtering is always wrong, ev= en
when requested by the user". Martin laid out our thinking in some
detail, but I'll try to summarize here.

1. In the long term, we do not believe that unilateral filtering = by
network entities is viable. Without some engagement/consent by th= e
"owner of the endsystem" then filtering by parties which the owne= r
might perceive as legitimate is indistinguishable from attack.

2. If the owner of the endsystem consents, then DNS filtering is = a
viable mechanism, though we don't think it's the best point to do
filtering at, in part because the granularity of filtering is qui= te
coarse (compare, for instance, Safe Browsing, which operates at a= URL
prefix level). However, that seems like a reasonable set of
technological tradeoffs for people to make and Mozilla's TRR poli= cies
explicitly state that "Resolvers may block or filter content with= the
user=E2=80=99s explicit consent."

3. In the short term, we are aware that there is DNS filtering
(principally parental controls) which is performed with user cons= ent
by non-TRR resolvers. To avoid breaking those environments, we ha= ve
implemented a set of mechanism (principally the canary) to attemp= t to
detect those cases and disable DoH. However, because this allows = for
active downgrade attack, we do not consider the canary mechanism
viable in the long-term, and would expect to eventually require
some engagement with the endsystem to disable DoH.
Of course you are authoritative for your own views, so thanks for clarif= ying them. So would it be more precise to say that in Mozilla's view DNS fi= ltering is wrong when
a) it is done without the consent of the user, or
b) it is done with the consent of the user by non-TRR resolvers?
(a use case which, as you say in #3, you are allowing temporarily but w= ill disable in the long term, with the suggestion that either those resolve= rs become TRRs or get their users to actively disable DoH once you turn it = on by default)

Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say that= your problem with the two use cases is not that filtering is wrong, but th= at it is not viable securely. So, if we devised a way to do it securely, wo= uld you consider those use cases legitimate and support them in Firefox?

-- 

Vittorio Bertola | Head of Policy & Innovation, Open=
-Xchange
vittorio.b=
ertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Ital=
y
=20 From nobody Sat Oct 5 08:43: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 15AB91208DE for ; Fri, 4 Oct 2019 10:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 HPM2lQQGsE6N for ; Fri, 4 Oct 2019 10:36:25 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.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 6E7EB12008D for ; Fri, 4 Oct 2019 10:36:25 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x94HWPPc015208 for ; Fri, 4 Oct 2019 10:36:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : message-id : references : to : date; s=20180706; bh=QeLsiFnTsMM6+6GOnRcKyE7NbKdX18Wn+sCDJSN6hRU=; b=bzb49A73fOrDjN3HYzE1xKuimQlinXZoqAD7XxGYpR6IjtlmSQFAYqrkM2mQpkfTUSWK h1XyifaZQczH/ttKs970FP1vZZd+BH4PE0ati2pAUe7oytCSFvkpAWFRU1kGUp25MixZ hzD+hXCp657ZPGAcYd15wrD5qaexQocSKVsmZ6KxhyUjdA41WLwvgK/KbZaY+18kQXzz 7j7tY28b8J8qb6jGlJGVhohW2qEgUG/pWPFJdv9e7HuyYJWXQlud/nsvgORpUwsZ8Tho f8Mgkmr7SZTVzelyvnj86mwtTrVFjA+wsOOLXAv5by06Ghx9GBEgBeXOqf4HvtvqpnCS Qw== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2vaqrn2rxk-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 04 Oct 2019 10:36:25 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PYV00ES128ER730@ma1-mtap-s02.corp.apple.com> for add@ietf.org; Fri, 04 Oct 2019 10:36:15 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PYV0010023FU200@nwk-mmpp-sz12.apple.com> for add@ietf.org; Fri, 04 Oct 2019 10:36:14 -0700 (PDT) X-Va-A: X-Va-T-CD: 221abde68e6359e30a5cccbd17ef49f2 X-Va-E-CD: 959b3d7444e88a27d60060ae1ec81f90 X-Va-R-CD: 1abdbdb1759a42c68512b5217d56b319 X-Va-CD: 0 X-Va-ID: 81b038f3-9faa-495f-81c6-ddeeac6f0053 X-V-A: X-V-T-CD: 221abde68e6359e30a5cccbd17ef49f2 X-V-E-CD: 959b3d7444e88a27d60060ae1ec81f90 X-V-R-CD: 1abdbdb1759a42c68512b5217d56b319 X-V-CD: 0 X-V-ID: 3437ffe1-ab9d-475d-8e8e-d884d30d2746 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-04_10:,, signatures=0 Received: from [17.234.11.210] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PYV007UY28DSC70@nwk-mmpp-sz12.apple.com> for add@ietf.org; Fri, 04 Oct 2019 10:36:14 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_D1D5C7F5-EC46-4439-9525-4D8E46BA1721" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Message-id: References: To: add@ietf.org Date: Fri, 04 Oct 2019 10:36:09 -0700 X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-04_10:, , signatures=0 Archived-At: X-Mailman-Approved-At: Sat, 05 Oct 2019 08:43:00 -0700 Subject: [Add] Fwd: Adaptive DNS Privacy and Oblivious 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, 04 Oct 2019 17:36:27 -0000 --Apple-Mail=_D1D5C7F5-EC46-4439-9525-4D8E46BA1721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Forwarding this message from the DPRIVE list, since these documents fit = well into the topics for ADD: > Begin forwarded message: >=20 > Hello DNS Privacy, >=20 > We=E2=80=99ve published a set of new drafts that define what we=E2=80=99= re calling =E2=80=9CAdaptive DNS Privacy=E2=80=9D. This is an approach = to using technologies like DoH to improve privacy of name resolution = without breaking the functionality provided by local network resolvers. = It also does not require placing trust in one or more fixed resolvers, = but instead allows server deployments to dynamically indicate which = resolvers are designated for their zones. >=20 > =46rom the perspective of an operating system vendor (for myself, iOS = and macOS), the goal is to use this approach to DNS privacy in the = system stub resolver such that it can be safely and automatically used = by all applications. >=20 > The first draft is =E2=80=9CAdaptive DNS: Improving Privacy of Name = Resolution=E2=80=9D. > https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy = >=20 > This covers the overall architecture for both clients and server = deployments. This includes: >=20 > =E2=80=A2 A mechanism for clients to discover DoH resolvers that = are =E2=80=9Cdesignated=E2=80=9D for certain names or zones, using a = DNSSEC-signed SVCB record = (https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc = ). > =E2=80=A2 An algorithm for clients to select which resolver to = use for a given name based on precedence (defining how VPNs, local = network resolvers, designated cloud-based resolvers, and Oblivious DoH = lookups coexist). > =E2=80=A2 A mechanism for local networks to advertise their = rules and capabilities using a provisioning domain = (https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains = ); = this allows the advertisement of a locally-designated DoH server, a list = of names or zones over which the local network claims authority, and an = indication of filtering requirements. >=20 > The second draft is =E2=80=9COblivious DNS Over HTTPS=E2=80=9D, which = we refer to as ODoH.=20 > https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh = >=20 > Inspired by Oblivious DNS = (https://tools.ietf.org/html/draft-annee-dprive-oblivious-dns = ), this = draft adds an extension to DoH for encrypting queries such that a = resolver cannot know both the client=E2=80=99s IP address and the = content of the DNS query. In contrast to Oblivious DNS, ODoH uses HTTP = proxying to unlink query sources and destinations. (ODoH also uses HPKE = (https://tools.ietf.org/html/draft-irtf-cfrg-hpke) for query public key = encryption.) >=20 > Please take a read through the documents and provide feedback. We=E2=80=99= re eager to iterate on these goals with the community. >=20 > You can also provide feedback and input on the GitHub repo: = https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy. >=20 > If you are interested in working on implementing any of these = protocols, please reach out for interop testing, etc.=20 >=20 > Best, > Tommy, Chris, Eric, and Patrick --Apple-Mail=_D1D5C7F5-EC46-4439-9525-4D8E46BA1721 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Forwarding this message from the DPRIVE list, since these = documents fit well into the topics for ADD:

Begin forwarded message:

Hello DNS Privacy,

We=E2=80=99ve published a set of new drafts = that define what we=E2=80=99re calling =E2=80=9CAdaptive DNS Privacy=E2=80= =9D. This is an approach to using technologies like DoH to improve = privacy of name resolution without breaking the functionality provided = by local network resolvers. It also does not require placing trust = in one or more fixed resolvers, but instead allows server deployments to = dynamically indicate which resolvers are designated for their zones.

=46rom the perspective of an operating system = vendor (for myself, iOS and macOS), the goal is to use this approach to = DNS privacy in the system stub resolver such that it can be safely and = automatically used by all applications.

The = first draft is =E2=80=9CAdaptive DNS: Improving Privacy of Name = Resolution=E2=80=9D.
https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-pri= vacy

This covers = the overall architecture for both clients and server deployments. This = includes:

=E2=80=A2 = A mechanism for clients to discover DoH resolvers that are = =E2=80=9Cdesignated=E2=80=9D for certain names or zones, using a = DNSSEC-signed SVCB record (https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc).
=E2=80=A2 An algorithm for = clients to select which resolver to use for a given name based on = precedence (defining how VPNs, local network resolvers, designated = cloud-based resolvers, and Oblivious DoH lookups coexist).
=E2=80=A2 A mechanism for local = networks to advertise their rules and capabilities using a provisioning = domain (https://tools.ietf.org/html/draft-ietf-intarea-provisioning-dom= ains); this allows the advertisement of a locally-designated DoH = server, a list of names or zones over which the local network claims = authority, and an indication of filtering requirements.

The second draft is =E2=80=9COblivious = DNS Over HTTPS=E2=80=9D, which we refer to as ODoH. 
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh

Inspired by = Oblivious DNS (https://tools.ietf.org/html/draft-annee-dprive-oblivious-dns), this draft adds an extension to DoH for encrypting queries such that = a resolver cannot know both the client=E2=80=99s IP address and the = content of the DNS query. In contrast to Oblivious DNS, ODoH uses = HTTP proxying to unlink query sources and destinations. (ODoH also uses = HPKE (https://tools.ietf.org/html/draft-irtf-cfrg-hpke) for = query public key encryption.)

Please take a = read through the documents and provide feedback. We=E2=80=99re eager to = iterate on these goals with the community.

You can also provide feedback and input on the GitHub = repo: https://github.com/tfpauly/draft-pauly-adaptive-dns-privacy= .

If you are interested in working on = implementing any of these protocols, please reach out for interop = testing, etc. 

Best,
Tommy, Chris, Eric, and Patrick

= --Apple-Mail=_D1D5C7F5-EC46-4439-9525-4D8E46BA1721-- From nobody Sat Oct 5 08:43: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 34702120059 for ; Fri, 4 Oct 2019 17:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gntv0Bx4ClRo for ; Fri, 4 Oct 2019 17:47:26 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 220AB120052 for ; Fri, 4 Oct 2019 17:47:26 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id y127so5674552lfc.0 for ; Fri, 04 Oct 2019 17:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q+kdQa/S66Rv9CzL3e6prS19i15A3sl3FQogEeyTxy4=; b=ZB34+nQHa8W2zQ1Q1TviP+QTFWf5OCoXSG2PzwYZZ9u5lh0Eu74/NaXUTeV/UOH8AN LN9/hGyd/qvl+uTARA3IGNGj3yEMjRttvqAfqNRWcwZz5dgHn4VsyGIeYwQPS55zB6nK XXv7k+NmklvmnUGTpRIrK1t+sEHv107hRLNair08Oyxfaio11l9plXsvgPdDJ0cfheX7 HXKQlnpB1yLikVp7G0KMMRFFp5zJ2QVcvLJhLD+c1q6PY8tMD8xm8RuqdeceVWLselXk XQtyj0qiUlmz2GvTxjHlv++nRfX+PSFTSgLiE0MbjRbU+z7SYQr/1mPmssUQ4o21/vEY zD/A== 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=Q+kdQa/S66Rv9CzL3e6prS19i15A3sl3FQogEeyTxy4=; b=coO1y7yKf8jW8qonsTDNQJbBiGYeRd/lDqPFj5Zx01e/pPLbq7a0SsfYlrM/rXKbRL uVscNrnJIZAMMDtb27PVgAodsz93YwcqvcJFXXFgrz/VSIZDyJMYdkbNaqwftpEDXDHI KAl70/Wer6AdfbAvefkee1xh1kDb6AwDYZzTBYE/GkojMFDYxy1ub2e7xKcDtdRp1wuC SMuS9eGEA32ePR3ujVpVU6W5XStus23SknL8i98lR/hzhOmEnVTPXI7/Ib7DwxuQD2Cf cuNbN3hqQWGIYE0tJfEjb49U79DPnKglfzjRjfLSXErvgYETUfi6Pmfb9KCbCHm5tfKS 2FvA== X-Gm-Message-State: APjAAAXLBRGS2958yQkhuB8qhvugyRckpLEeRKeV73uYoz+k/VIIfmYv qkx4qNg20RaEKhYrTE8EY/hthFY3Uj7ednrMt77DvQ== X-Google-Smtp-Source: APXvYqzfkA4WgEjRGgyaYG2tZ7BwrNDdrkfhdKQu44svnSFNIh7Zymx04ngBOR9xGxHh/5+0Iz1r9L1LKM27/rn9wt8= X-Received: by 2002:a19:6a09:: with SMTP id u9mr2176287lfu.91.1570236444334; Fri, 04 Oct 2019 17:47:24 -0700 (PDT) MIME-Version: 1.0 References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> <1428589845.15401.1570205467043@appsuite-gw2.open-xchange.com> In-Reply-To: <1428589845.15401.1570205467043@appsuite-gw2.open-xchange.com> From: Eric Rescorla Date: Fri, 4 Oct 2019 17:46:48 -0700 Message-ID: To: Vittorio Bertola Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007a74c505941f29ad" Archived-At: X-Mailman-Approved-At: Sat, 05 Oct 2019 08:43:26 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 05 Oct 2019 00:47:29 -0000 --0000000000007a74c505941f29ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Of course you are authoritative for your own views, so thanks for > clarifying them. So would it be more precise to say that in Mozilla's > view DNS filtering is wrong when > > a) it is done without the consent of the user, or > > b) it is done with the consent of the user by non-TRR resolvers? (a > use case which, as you say in #3, you are allowing temporarily but > will disable in the long term, with the suggestion that either those > resolvers become TRRs or get their users to actively disable DoH once > you turn it on by default) > > Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say > that your problem with the two use cases is not that filtering is > wrong, but that it is not viable securely. So, if we devised a way to > do it securely, would you consider those use cases legitimate and > support them in Firefox? As I said in my previous message, I don't think having you try to paraphrase our views is really helping. I think our position is reasonably clear, but just to sharpen one point: we already do support these use cases by allowing endsystem owners to configure any DNS resolver of their choice, whether it is part of the TRR program or not, and we intend to continue that policy. -Ekr On Fri, Oct 4, 2019 at 9:11 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 4 ottobre 2019 17:30 Eric Rescorla ha scritto: > > Mozilla's position is not "that DNS filtering is always wrong, even > when requested by the user". Martin laid out our thinking in some > detail, but I'll try to summarize here. > > 1. In the long term, we do not believe that unilateral filtering by > network entities is viable. Without some engagement/consent by the > "owner of the endsystem" then filtering by parties which the owner > might perceive as legitimate is indistinguishable from attack. > > 2. If the owner of the endsystem consents, then DNS filtering is a > viable mechanism, though we don't think it's the best point to do > filtering at, in part because the granularity of filtering is quite > coarse (compare, for instance, Safe Browsing, which operates at a URL > prefix level). However, that seems like a reasonable set of > technological tradeoffs for people to make and Mozilla's TRR policies > explicitly state that "Resolvers may block or filter content with the > user=E2=80=99s explicit consent." > > 3. In the short term, we are aware that there is DNS filtering > (principally parental controls) which is performed with user consent > by non-TRR resolvers. To avoid breaking those environments, we have > implemented a set of mechanism (principally the canary) to attempt to > detect those cases and disable DoH. However, because this allows for > active downgrade attack, we do not consider the canary mechanism > viable in the long-term, and would expect to eventually require > some engagement with the endsystem to disable DoH. > > Of course you are authoritative for your own views, so thanks for > clarifying them. So would it be more precise to say that in Mozilla's vie= w > DNS filtering is wrong when > a) it is done without the consent of the user, or > b) it is done with the consent of the user by non-TRR resolvers? > (a use case which, as you say in #3, you are allowing temporarily but wil= l > disable in the long term, with the suggestion that either those resolvers > become TRRs or get their users to actively disable DoH once you turn it o= n > by default) > > Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say that > your problem with the two use cases is not that filtering is wrong, but > that it is not viable securely. So, if we devised a way to do it securely= , > would you consider those use cases legitimate and support them in Firefox= ? > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --0000000000007a74c505941f29ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Of course you are authoritative for your own views, s= o thanks for
> clarifying them. So would it be more precise to say th= at in Mozilla's
> view DNS filtering is wrong when
>
&g= t; a) it is done without the consent of the user, or
>
> b) it= is done with the consent of the user by non-TRR resolvers? =C2=A0(a
>= ; use case which, as you say in #3, you are allowing temporarily but
>= ; will disable in the long term, with the suggestion that either those
&= gt; resolvers become TRRs or get their users to actively disable DoH once> you turn it on by default)
>
> Also, is "wrong&quo= t; the wrong word? Both in #1 and #3, you seem to say
> that your pro= blem with the two use cases is not that filtering is
> wrong, but tha= t it is not viable securely. So, if we devised a way to
> do it secur= ely, would you consider those use cases legitimate and
> support them= in Firefox?

As I said in my previous message, I don't think hav= ing you try to
paraphrase our views is really helping.

I think ou= r position is reasonably clear, but just to sharpen one
point: we alread= y do support these use cases by allowing endsystem
owners to configure a= ny DNS resolver of their choice, whether it
is part of the TRR program o= r not, and we intend to continue that
policy.

-Ekr

<= div class=3D"gmail_quote">
On Fri, Oct= 4, 2019 at 9:11 AM Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
=20 =20 =20

Il 4 ottobre 2019 17:30 Eric Rescorla <ekr@rtfm.com> ha scritto:

Mozilla's position is not "that DNS filtering is always = wrong, even
when requested by the user". Martin laid out our thinking in= some
detail, but I'll try to summarize here.

1. In the long term, we do not believe that unilateral filtering = by
network entities is viable. Without some engagement/consent by th= e
"owner of the endsystem" then filtering by parties whic= h the owner
might perceive as legitimate is indistinguishable from attack.

2. If the owner of the endsystem consents, then DNS filtering is = a
viable mechanism, though we don't think it's the best poi= nt to do
filtering at, in part because the granularity of filtering is qui= te
coarse (compare, for instance, Safe Browsing, which operates at a= URL
prefix level). However, that seems like a reasonable set of
technological tradeoffs for people to make and Mozilla's TRR = policies
explicitly state that "Resolvers may block or filter content= with the
user=E2=80=99s explicit consent."

3. In the short term, we are aware that there is DNS filtering
(principally parental controls) which is performed with user cons= ent
by non-TRR resolvers. To avoid breaking those environments, we ha= ve
implemented a set of mechanism (principally the canary) to attemp= t to
detect those cases and disable DoH. However, because this allows = for
active downgrade attack, we do not consider the canary mechanism
viable in the long-term, and would expect to eventually require
some engagement with the endsystem to disable DoH.
Of course you are authoritative for your own views, so thanks for clarif= ying them. So would it be more precise to say that in Mozilla's view DN= S filtering is wrong when
a) it is done without the consent of the user, or
b) it is done with the consent of the user by non-TRR resolvers?
(a use case which, as you say in #3, you are allowing temporarily but w= ill disable in the long term, with the suggestion that either those resolve= rs become TRRs or get their users to actively disable DoH once you turn it = on by default)

Also, is "wrong" the wrong word? Both in #1 and #3, you seem t= o say that your problem with the two use cases is not that filtering is wro= ng, but that it is not viable securely. So, if we devised a way to do it se= curely, would you consider those use cases legitimate and support them in F= irefox?

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--0000000000007a74c505941f29ad-- From nobody Sat Oct 5 08:43: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 1CF5C12004E for ; Sat, 5 Oct 2019 00:48:16 -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_HELO_NONE=0.001, 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 Hv_pfF_qTWz3 for ; Sat, 5 Oct 2019 00:48:13 -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 CC39D1200C1 for ; Sat, 5 Oct 2019 00:48:13 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id v2so18401857iob.10 for ; Sat, 05 Oct 2019 00:48:13 -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=8GkAPhImj7PHnPkas+3R95QBuPWjyH+1nyGgqg4XtcM=; b=j9MXJs/b5L4PQ81fvla08DgYjjBG9LaylbRVU0XhBFfMuSSmLxTT1WEpnSacsdB1Tf Dgzet2FB5SB3Q0IIzq6/qwvFVzCqeQ+npBRqI7kCXpOf2RByukpD3TOu/3I43PTUZl1s rCWaHhYyEJfrOTaxqPSsdD2lf12GRSlSwuXcAmKB1PnPPnLGC1boJESO67n3Kd0ezoKa 64MU8FSVJvv2gl/LMK07VZ9SWzUExDKpJv3CKHEtuiKIobei48X7mSQ2h2OaNo2vfyfM tJXWozVElijSnilcz2aqYn8sDGuv585b8A4Hu6jIgB8ahlPX0IndZifvoGO0QPH2Tp1e QxcQ== 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=8GkAPhImj7PHnPkas+3R95QBuPWjyH+1nyGgqg4XtcM=; b=aSxOGSE+SRAioyVrvxSLVp7yCgK1UTds5mjuf6bgi237yRusSSniX4Mu7g6vpxl+Dj L+v+paFXvM6CIT4OVc72uEi5+I+9aE/c/Gt4i68XVkzV9lAvN1JBUNAB07y8+56zh6FJ TYXy/ktRErQ1SOQAZPwDAYpBBdMZLSMEOf3CwXEbwVW0y1eiLYARxb9UjCpFMwvI45iH cTeOm6zR1isK0fTGclQbdYlCQoJkOuC60GGd2RvErHCtTqfxFFy3pz7rwQSwSZ2AnT9E gEQ6kEJ4QqY34vUew5lRaxr4CAIRDSwbRZbM0PBbVSnBSQ1sk3fdCwiJoK9oqLdgz95Y 9Vkg== X-Gm-Message-State: APjAAAVSOPGTNXbtjCZmjvgPDR+cUHhZJ05LFtZbMqlDv94ptP+qLwes vBitgcRHjWie6eSc00+2G6jtiXyqAIL03Ll1JhXZKg== X-Google-Smtp-Source: APXvYqzYukwzZmJXCIJXAzTk4c7HwuUzsp9v5FBGIz3e/URH2SL8zC8NzGoDNJ1SQrgo+P3VgnQs0JiPnGYc3EucqLc= X-Received: by 2002:a92:8c86:: with SMTP id s6mr3661019ill.298.1570261692971; Sat, 05 Oct 2019 00:48:12 -0700 (PDT) MIME-Version: 1.0 References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> In-Reply-To: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> From: tirumal reddy Date: Sat, 5 Oct 2019 13:17:59 +0530 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000006a000f0594250a6a" Archived-At: X-Mailman-Approved-At: Sat, 05 Oct 2019 08:43:45 -0700 Subject: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 05 Oct 2019 07:48:16 -0000 --0000000000006a000f0594250a6a Content-Type: text/plain; charset="UTF-8" Hi all, We have published https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that discusses a mechanism for the DNS server to communicate its cryptographically signed privacy policy information to a DNS client. By evaluating the DNS privacy policy and the signatory, the DNS client can choose to select or avoid a DoT/DoH server if it doesn't comply with the client's privacy expectations. Comments, suggestions and questions are more than welcome. Cheers, -Tiru ---------- Forwarded message --------- From: Date: Thu, 3 Oct 2019 at 15:59 Subject: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt To: Tirumaleswar Reddy , Dan Wing , Michael C. Richardson A new version of I-D, draft-reddy-dprive-dprive-privacy-policy-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-dprive-dprive-privacy-policy Revision: 00 Title: DNS server privacy policy with assertion token Document date: 2019-10-03 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-reddy-dprive-dprive-privacy-policy-00.txt Status: https://datatracker.ietf.org/doc/draft-reddy-dprive-dprive-privacy-policy/ Htmlized: https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-dprive-dprive-privacy-policy Abstract: Users want to control how their DNS queries are handled by DNS servers so they can configure their system to use DNS servers that comply with their privacy expectations. This document defines a mechanism for a DNS server to communicate its privacy policy to a DNS client. This communication is cryptographically signed to attest to its authenticity. By evaluating the DNS privacy policy and the signatory, the DNS client can choose a DNS server that best supports its desired privacy policies. The privacy assertion token is particularly useful for DNS-over-TLS and DNS-over-HTTPS servers, both public resolvers and those discovered on the local network. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000006a000f0594250a6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We have published=C2=A0https://tools.ietf.org/html/draft-reddy-dprive-dpr= ive-privacy-policy-00=C2=A0that discusses a mechanism for the DNS serve= r to communicate its cryptographically signed privacy policy information to= a DNS client. By evaluating the DNS privacy policy and the signatory, the = DNS client can choose to =C2=A0select or avoid a DoT/DoH server if it doesn= 't comply with the client's privacy expectations.

Comments,= suggestions and questions are more than welcome.

Cheers,
-Tiru
----= ------ Forwarded message ---------
From: <internet-drafts@ietf= .org>
Date: Thu, 3 Oct 2019 at 15:59
Subject: New Versi= on Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt
To: = Tirumaleswar Reddy <kondtir@gmail.com>, Dan Wing <dwing-ietf@fuggles.com>, Michael C. Rich= ardson <mcr= +ietf@sandelman.ca>



A new version of I-D, draft-reddy-dprive-dprive-privacy-policy-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-dprive-dprive-pri= vacy-policy
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DNS server privacy policy with ass= ertion token
Document date:=C2=A0 2019-10-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-re= ddy-dprive-dprive-privacy-policy-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-dprive-dprive-p= rivacy-policy/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy= -00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-reddy-dprive-dpri= ve-privacy-policy


Abstract:
=C2=A0 =C2=A0Users want to control how their DNS queries are handled by DNS=
=C2=A0 =C2=A0servers so they can configure their system to use DNS servers = that
=C2=A0 =C2=A0comply with their privacy expectations.

=C2=A0 =C2=A0This document defines a mechanism for a DNS server to communic= ate its
=C2=A0 =C2=A0privacy policy to a DNS client.=C2=A0 This communication is =C2=A0 =C2=A0cryptographically signed to attest to its authenticity.=C2=A0 = By
=C2=A0 =C2=A0evaluating the DNS privacy policy and the signatory, the DNS c= lient
=C2=A0 =C2=A0can choose a DNS server that best supports its desired privacy=
=C2=A0 =C2=A0policies.=C2=A0 The privacy assertion token is particularly us= eful for
=C2=A0 =C2=A0DNS-over-TLS and DNS-over-HTTPS servers, both public resolvers= and
=C2=A0 =C2=A0those discovered on the local network.




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

The IETF Secretariat

--0000000000006a000f0594250a6a-- From nobody Sun Oct 6 10:56: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 D8A12120859 for ; Sat, 5 Oct 2019 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBYncIOakUSs for ; Sat, 5 Oct 2019 09:07:03 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 200E1120858 for ; Sat, 5 Oct 2019 09:07:03 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id h144so19956287iof.7 for ; Sat, 05 Oct 2019 09:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mn7KltC4EzYv6j3fC3efYi3mIytwh5u6TIMxAuwtuAU=; b=FFL0x45D6jQHrgwv+30O+vOcf33b7LqYXGEKRXP2sQngOZPCVpwhDRzYAXDjLoTfK6 ETI82pudtn+Inf5zNPoucWm7ypojZK+DtZ3xjVs4n2mwwiimkND279haNS/VwgNOysxM 1zA2SPNCMDnT25u+/x9cCgi7/6Sjp1TsGsEg3e0VDCSF8F2fYx+AW/LKHkBMWqDb0ZEY NiwVL4kN7qwp3f87bnIfD1i0quQrQhkxC8rZkN6E7vAXEMOfjjPP7/u1BGBLuz46s4dp z9vIbENx4vX7EujeAg4VNcIqcKqQ10WwPooiCIj+HhCeSSxeZXMGV5zkEEp5w4CUjNH6 IL/g== 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=mn7KltC4EzYv6j3fC3efYi3mIytwh5u6TIMxAuwtuAU=; b=e7KnW8Nfca8gdtbH+Thju336d5gEtSwLV4Rk+PGlvmVqalATBP1BKswjok65Cmz7Y1 bFMwANcKVQ8SFvoPuIJYo/Yb7eSv8ViCzwKsk5UDUmEw0qQ9+R3AS7MNUIq/3tASrJYf 9VGhOd3GlHLCzVvCeh+HwFpOd7FfFvsTmUl53fW/mnN0yDD3M4AxEYnJG8aW/waVHHNY t5+VJTF7ObZ3QTqBxy8RhZI4SuFHSCvxmuIfDUe0ggyNQnUnTpHolWKAgTRgSWJ1+XZa 8nxdHH/YSVMxuxaUS6uI/JBlyqs/gn1RwBQVMZ893ofexGjLJIHMw13aVqGNULaAuxj5 C97Q== X-Gm-Message-State: APjAAAX6Ry7KTIYZ1YdFOZKj1G/g48Y/S4+w8weCLIVXC+CdeKk4B5Eh /oz0nTkEysLPHUuI0c4tk7q9fg== X-Google-Smtp-Source: APXvYqyBN7PZrwqSAbr6V0tSK3H6kB/pIz/7H6eR2yhWFf5VS5XDc98S4Q9SGYVKlSllyFdSQWZXfw== X-Received: by 2002:a6b:5b0a:: with SMTP id v10mr17956503ioh.80.1570291622282; Sat, 05 Oct 2019 09:07:02 -0700 (PDT) Received: from [172.19.0.56] ([75.104.91.167]) by smtp.gmail.com with ESMTPSA id 13sm3944598ilz.54.2019.10.05.09.06.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Oct 2019 09:07:01 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_37E7C3EE-508E-4F1A-A930-B2BD6082558B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) Date: Sat, 5 Oct 2019 09:06:42 -0700 In-Reply-To: Cc: Vittorio Bertola , ADD Mailing list , Dave Lawrence To: Eric Rescorla References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> X-Mailer: Apple Mail (2.3600) Archived-At: X-Mailman-Approved-At: Sun, 06 Oct 2019 10:56:50 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 05 Oct 2019 16:07:05 -0000 --Apple-Mail=_37E7C3EE-508E-4F1A-A930-B2BD6082558B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 4, 2019, at 8:30 AM, Eric Rescorla wrote: > If the owner of the endsystem consents, then DNS filtering is a > viable mechanism, though we don't think it's the best point to do > filtering at, in part because the granularity of filtering is quite > coarse (compare, for instance, Safe Browsing, which operates at a URL > prefix level). I completely agree with your appeal to clarity, but that said I wanted = to point out an assumption embedded here, which makes sense for Mozilla = but does not make sense in general. The assumption is that the thing = doing the filtering will get to see the URL. This assumption doesn=E2=80=99t hold for the use case most people have = been talking about here: stopping connections to botnet C&C servers. --Apple-Mail=_37E7C3EE-508E-4F1A-A930-B2BD6082558B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 4, 2019, at 8:30 AM, Eric Rescorla <ekr@rtfm.com> wrote:
If the owner of the endsystem consents, then DNS filtering is = a
viable = mechanism, though we don't think it's the best point to do
filtering at, in part because = the granularity of filtering is quite
coarse (compare, for instance, Safe Browsing, which operates = at a URL
prefix = level).

I = completely agree with your appeal to clarity, but that said I wanted to = point out an assumption embedded here, which makes sense for Mozilla but = does not make sense in general.   The assumption is that the thing = doing the filtering will get to see the URL.

This assumption doesn=E2=80=99t hold = for the use case most people have been talking about here: stopping = connections to botnet C&C servers.

= --Apple-Mail=_37E7C3EE-508E-4F1A-A930-B2BD6082558B-- From nobody Sun Oct 6 10:58: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 DE6A71200DF for ; Sat, 5 Oct 2019 10:41:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 KosNm5u47RuD for ; Sat, 5 Oct 2019 10:41: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 EC8D3120048 for ; Sat, 5 Oct 2019 10:41:37 -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 BC51C6A28A; Sat, 5 Oct 2019 19:41:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570297295; bh=7cZlENsQX5L3lpZ2xIlkAH76cH4XbemX8IDIMfyS+6g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=X22e9YT9mlm51giV1AiF9eTcEna+bOUWqDI3T9DRcQb0KA418UsXePlGk+sTBi+TW wz+FJuMPFK3slIfQCi42rFhrqo7jBLiUmruqpzgnofIpcBJ5IHH8prSmmw0RXomiio kwV6O6fo34Byjdki/8prLt7Jwpa6TDtVI91rHOooXEEXN9eVlGxjss5HoemIaaibln xDYuF4TVb1Q7t7hsV8nkLyRPkKLy2/5rnedgqi4GxDn8srblmz8w8pJfI5cQBHQcxQ epPO4g/v8NRbnMZpVu/4pIVW4h74FKK+eGcQPb1KsHNef/R9QfN0B3Z2xR4XAA+YTh AWF3/Zb4+wQ3A== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A40013C002F; Sat, 5 Oct 2019 19:41:35 +0200 (CEST) Date: Sat, 5 Oct 2019 19:41:35 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Eric Rescorla Cc: ADD Mailing list Message-ID: <857698664.20536.1570297295563@appsuite-gw1.open-xchange.com> In-Reply-To: References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> <1428589845.15401.1570205467043@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: X-Mailman-Approved-At: Sun, 06 Oct 2019 10:58:09 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 05 Oct 2019 17:41:40 -0000

Il 5 ottobre 2019 02:46 Eric Rescorla <ekr@rtfm.com> ha scritto:


> Of course you are authoritative for your own views, so thanks for
> clarifying them. So would it be more precise to say that in Mozilla's
> view DNS filtering is wrong when
>
> a) it is done without the consent of the user, or
>
> b) it is done with the consent of the user by non-TRR resolvers?  (a
> use case which, as you say in #3, you are allowing temporarily but
> will disable in the long term, with the suggestion that either those
> resolvers become TRRs or get their users to actively disable DoH once
> you turn it on by default)
>
> Also, is "wrong" the wrong word? Both in #1 and #3, you seem to say
> that your problem with the two use cases is not that filtering is
> wrong, but that it is not viable securely. So, if we devised a way to
> do it securely, would you consider those use cases legitimate and
> support them in Firefox?

As I said in my previous message, I don't think having you try to
paraphrase our views is really helping.
I am trying to paraphrase and repeat your views because it is the only possible way to make sure that I understood them correctly, which is necessary to figure out constructive proposals for the future. (It is actually the recommended method for moderators, negotiators and journalists doing interviews.)

For example, as pointed out in my last paragraph above, I have not understood whether Mozilla objects to in-network, non-consensual filtering on a principle basis (i.e., it is ethically and architecturally wrong because it can also be used for censorship) or on a practical basis (i.e., you do not support it because you think it does not work in a secure way). If your position were the latter, we could imagine of working together at the IETF to find secure ways to do it, while if it were the former, trying to do that with you would be a waste of time for everyone.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Sun Oct 6 10:58: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 985F1120861 for ; Sat, 5 Oct 2019 10:58:10 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 wlfkxQs6lOVP for ; Sat, 5 Oct 2019 10:58:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 12F98120072 for ; Sat, 5 Oct 2019 10:58:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46lvbx2W4rzFhg; Sat, 5 Oct 2019 19:58:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570298285; bh=osFUfLS/+JdWBkvJVqITbsZT5oqGj5Y84O+rEjWOjpw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Gpz7bE/V5aLXU/F93+11RsZSibC70+qcaiypXh3GBSCY0mHxLCbZycuwDE6HP/CmH c96vkkf6Yd2pusN2O9wWaqESwFhSEatewpdeRAN2NYnUYhz/p30S25/n7R/SGEQNwj WFKSGVjDYvtBolDo/1a9r8mzNsjSAHtC0tAcw3lo= 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 KdSPLCoWn-kI; Sat, 5 Oct 2019 19:58:03 +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; Sat, 5 Oct 2019 19:58:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C431278BA5; Sat, 5 Oct 2019 13:58:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C431278BA5 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B8B13406B80E; Sat, 5 Oct 2019 13:58:01 -0400 (EDT) Date: Sat, 5 Oct 2019 13:58:01 -0400 (EDT) From: Paul Wouters To: tirumal reddy cc: ADD Mailing list In-Reply-To: Message-ID: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: X-Mailman-Approved-At: Sun, 06 Oct 2019 10:58:47 -0700 Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 05 Oct 2019 17:58:11 -0000 On Sat, 5 Oct 2019, tirumal reddy wrote: > We have published https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that discusses a mechanism for the > DNS server to communicate its cryptographically signed privacy policy information to a DNS client. By evaluating the DNS > privacy policy and the signatory, the DNS client can choose to  select or avoid a DoT/DoH server if it doesn't comply with > the client's privacy expectations. Section 10 Security Considerations describes well why I think this is not a good idea. Publishing a privacy policy in a computer consumable way has no relationship to the actual DNS server's privacy policy used. This is not a technical wire problem to solve with an RFC. It is a social-economic issue. Can we trust vendor X? And vendor X making claims in JSON about this isn't useful from a technical point of view, no matter how or where and with what such statements are (self)signed. It's a great topic for consumer advocay organisations, the EFF or ACLU or EU commisioners. I do not think this is a technical problem needing a technical standard from the IETF. And any automated consumption of this leading to changed DNS client behaviour would be dangerous. Paul From nobody Sun Oct 6 10:59: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 BAB271200F3 for ; Sat, 5 Oct 2019 20:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmZMdhkurVIF for ; Sat, 5 Oct 2019 20:57:49 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 5F43012006E for ; Sat, 5 Oct 2019 20:57:49 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id r134so6977143lff.12 for ; Sat, 05 Oct 2019 20:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qeGVYvRIuI9pRJxJMuP7iUksZe0H1OeA60NjCFen1EQ=; b=O8eQ/gXJ10hkm71aPgAdvYi2367kZCR15rzumh9DwX5MNAxN4L+BEL1ZAC51hg8ajF unO3BPiZKnd5XaT7alW7pBhGDh5js78gxPF1070n4+VygLNj/YcoYLlV7zKaMWg9ra90 /5/rPSWaHamRxTLEFDk/xeffjssvXaQlNooTaxq6R4qaZBGti5nl1Fnocy35n6+yT7Yq vuZohsJC8iqt6U+ikFILKMBccdDOa/ZaRpCd3GrvwJTH0/MBe5iLrZvoSbz7dSzh9mHn aRA6SZ1tBuy7yD4m3ZoOo7UE94E+GlZvA+1A/YXhvC+kPeUVcsIHSRk6hNnwM2aYkr/5 4iTw== 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=qeGVYvRIuI9pRJxJMuP7iUksZe0H1OeA60NjCFen1EQ=; b=a2wUzYFzu4SpMZzwdDwQhaPRBXlVu0Lb3TF6UW+7YRQQ6TlqTDVPyGtiesiZWSclPi QU6vkwl4iulQyMkQPxL1uXXFx8yGlqJlP8pf0jAxaFPMEAuuJNDtC8yxh2iufvhhJiVi xyiahRpf4EKM4PTDjN00r/XN8UFKMx1J8sybtQyDN/oK4Z42IYMsF/7+ZheBJlpqxQrP TdFVZFVCw0DuUchARQrisRvkUq2BZrwR5E1mJi4dWiYPsd1BMI61ho3M7cXTD9DSV+HV bKj2D0uvsiYgmS2tcA5M9Y5eCvpUCGG9CP2aYq39wAJU/LmCczGfPximtsRlsBP4l32x uNfQ== X-Gm-Message-State: APjAAAWOZyb0zi06g654dpsptYUlVVeGgdbOZf0rks+WqUcf+Vd0qpHG xWIsY1TOrPvWJxowpEYnBr4UFXMqEyVjU8PL3oHQqQ== X-Google-Smtp-Source: APXvYqyJBeoScU61jIpufg3fj4vkHF/DGWWztr7xr/ceHZ4NM1uZu4QO58qoqnijfp1j4iS+O6276PqlH44U0l7sz9Y= X-Received: by 2002:a19:c80b:: with SMTP id y11mr13788660lff.184.1570334267579; Sat, 05 Oct 2019 20:57:47 -0700 (PDT) MIME-Version: 1.0 References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> In-Reply-To: From: Eric Rescorla Date: Sat, 5 Oct 2019 20:57:11 -0700 Message-ID: To: Ted Lemon Cc: Vittorio Bertola , ADD Mailing list , Dave Lawrence Content-Type: multipart/alternative; boundary="00000000000032b3c6059435f019" Archived-At: X-Mailman-Approved-At: Sun, 06 Oct 2019 10:59:19 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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: Sun, 06 Oct 2019 03:57:52 -0000 --00000000000032b3c6059435f019 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 5, 2019 at 9:07 AM Ted Lemon wrote: > On Oct 4, 2019, at 8:30 AM, Eric Rescorla wrote: > > If the owner of the endsystem consents, then DNS filtering is a > viable mechanism, though we don't think it's the best point to do > filtering at, in part because the granularity of filtering is quite > coarse (compare, for instance, Safe Browsing, which operates at a URL > prefix level). > > > I completely agree with your appeal to clarity, but that said I wanted to > point out an assumption embedded here, which makes sense for Mozilla but > does not make sense in general. The assumption is that the thing doing > the filtering will get to see the URL. > > This assumption doesn=E2=80=99t hold for the use case most people have be= en > talking about here: stopping connections to botnet C&C servers. > Right. Our position is that DNS filtering is not a long-term viable strategy for filtering when the endpoint wishing to do the resolution is adversarial. -Ekr --00000000000032b3c6059435f019 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Oct 5, 2019 at 9:07 AM Ted Le= mon <mellon@fugue.com> wrote:=
On Oct 4, 2019, at 8:30 AM, Eric Rescorla <ekr@rtfm.com> wrote:=
If the owner of the endsystem consents, then DNS filtering is a
via= ble mechanism, though we don't think it's the best point to do
filte= ring at, in part because the granularity of filtering is quite
coarse (compa= re, for instance, Safe Browsing, which operates at a URL
prefix level).

I completely agree with your appeal to = clarity, but that said I wanted to point out an assumption embedded here, w= hich makes sense for Mozilla but does not make sense in general. =C2=A0 The= assumption is that the thing doing the filtering will get to see the URL.<= /div>

This assumption doesn=E2=80=99t hold for the use c= ase most people have been talking about here: stopping connections to botne= t C&C servers.

Right. Our p= osition is that DNS filtering is not a long-term viable strategy for filter= ing when the endpoint wishing to do the resolution is adversarial.

-Ekr


=C2=A0
<= /div>
--00000000000032b3c6059435f019-- From nobody Mon Oct 7 07:04: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 6222C120072 for ; Sun, 6 Oct 2019 12:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 wAC0AP6cJXbd for ; Sun, 6 Oct 2019 12:31:20 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE4120048 for ; Sun, 6 Oct 2019 12:31:20 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.164.104]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id x96JDtpJ013453 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Oct 2019 12:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1570389246; x=1570475646; i=@elandsys.com; bh=UWRAE7/oOoQpLIcJsVe/bqzw6dtiXu2L/1IFrqy+VCc=; h=Date:To:From:Subject:In-Reply-To:References; b=twon0HpaiI4GFI7htDruUUUDBESx3RjSPKBoIDuE6FRb6YHF+nSxAEoswmnZTS+KL XlIFZQOm0e44hQM304RVgqI9gd2XDl/jGzzAaIC6mgEj/v1/6o0PhjPXo8/cKgJMYn 6muFKGMorxEtLI+sp2x0Qu/3PPpAUPTDWjPp5+dg= Message-Id: <6.2.5.6.2.20191006114851.12e500d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 06 Oct 2019 12:13:38 -0700 To: Ted Lemon From: S Moonesamy In-Reply-To: References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:04:40 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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: Sun, 06 Oct 2019 19:31:22 -0000 Hi Ted, At 09:06 AM 05-10-2019, Ted Lemon wrote: >I completely agree with your appeal to clarity, but that said I >wanted to point out an assumption embedded here, which makes sense >for Mozilla but does not make sense in general. The assumption is >that the thing doing the filtering will get to see the URL. > >This assumption doesn't hold for the use case most people have been >talking about here: stopping connections to botnet C&C servers. The application attempting to access the URL is not necessarily a web browser. It may be another application which depends on the system to provide the DNS resolution service. The "safe browsing" does not provide any protection for such cases. Regards, S. Moonesamy From nobody Mon Oct 7 07:05: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 8B6B8120048 for ; Sun, 6 Oct 2019 12:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCb-G6NoSAsZ for ; Sun, 6 Oct 2019 12:31:28 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 984CE120072 for ; Sun, 6 Oct 2019 12:31:27 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id f5so11386599ljg.8 for ; Sun, 06 Oct 2019 12:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHu28mA8p76qv3NVXDBSe3L36CaoACaw5Wn0Nv6fvs0=; b=dpk/vltGwrPSeA0S2AcQ4eTvizE7KObijAYZoyH+lGygi/t4WoJ0TGgTTOsaQNzSuT wtmlQo1D/mLAwz37I++gT61YnFQFwrXNL+5YKmd3Wol01ba2M/N79zw5LWNt7Q/o9O0o cp2ek//KY0Azu8v4CbEGz/Y4S5p2EK00gJ5fYzRz/KneiqUQVLAPWnf2nDfrfgWYaLLJ J82Qr9et04Jepl9oUyi6+eG+RR0Q3Ou0Xsn95sEy1sHx8DvAAsROi5AkNPO54/fL7JqK cZM/i9ow3Y28Pn2u1DjfBJjXyqauIG1jqgnMDv9ppjoDTS6OSiUE4/Grr5RLGbmHE+iF cZ2A== 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=XHu28mA8p76qv3NVXDBSe3L36CaoACaw5Wn0Nv6fvs0=; b=sJa1W6Uyoyx+HM+BuzzYJnQdmvM2qoKSf6jADUOGo9GSL/ITcRPKMQnk0LyvV6Yhk4 xVPJHWNMoFO4uLChZJzI5hZBHT6mF31bWv81zu163TuglfBGlLdRNXJ14SrIIlh85KXl tugbzxycVAPtkUMRHibeDKTMao5ESGktY5YIXye4Gp5iSQygWh47P+M7hDLdaXdHG0qW MSzr+wid+Lx6ptELX6/gWUPMNZms5DGJiwjuZJ6QtTD90RwmP6QTzmyAdYzgdZpcQyQF XIyk85FImfDb2g2I4ocAitF1YIFgSc4GbwhxDpxw0uUR7ETEm+XdATwR3HdQkCaipNrW jJRg== X-Gm-Message-State: APjAAAXiDm4RJcZZ30vMiP918XiU6QN0OMiafzAROKVVbtEmtYGLvrap gApFFsNezKDgsP1jQvnBnBRn2FOwtygaZrsuHAXhdQ== X-Google-Smtp-Source: APXvYqzFQgqrLShkEe49JRLvB9kjSd4UScNCKC0gVC97f6OvVszDcpAa9hjsX+xK1ThA7zNUy8u5xlMgQfIEDwEsWpY= X-Received: by 2002:a2e:9799:: with SMTP id y25mr16035251lji.38.1570390285854; Sun, 06 Oct 2019 12:31:25 -0700 (PDT) MIME-Version: 1.0 References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> In-Reply-To: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> From: Eric Rescorla Date: Sun, 6 Oct 2019 12:30:49 -0700 Message-ID: To: Ted Lemon Cc: Vittorio Bertola , ADD Mailing list , Dave Lawrence Content-Type: multipart/alternative; boundary="00000000000025bc7f059442fb87" Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:05:09 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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: Sun, 06 Oct 2019 19:31:30 -0000 --00000000000025bc7f059442fb87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 6, 2019 at 12:06 PM Ted Lemon wrote: > On Oct 5, 2019, at 22:57, Eric Rescorla wrote: > > Right. Our position is that DNS filtering is not a long-term viable > strategy for filtering when the endpoint wishing to do the resolution is > adversarial. > > Do you think there=E2=80=99s some better strategy, or do you just see thi= s as > impossible? As everything moves to being encrypted, generally strategies based on examining the plaintext of messages in the network will become less effective. This is one such mechanism. -Ekr --00000000000025bc7f059442fb87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Oct 6, 2019 at 12:06 PM Ted Lemon <mellon@fugue.com> wrote:
On Oct 5, 2019, at 22:57, Eric Rescorla &= lt;ekr@rtfm.com> w= rote:
> Right. Our position is that DNS filtering is not a long-term viable st= rategy for filtering when the endpoint wishing to do the resolution is adve= rsarial.

Do you think there=E2=80=99s some better strategy, or do you just see this = as impossible?=C2=A0

As everything moves to= being encrypted, generally strategies based on examining the plaintext of = messages in the network will become less effective. This is one such mechan= ism.

-Ekr


<= /div>
--00000000000025bc7f059442fb87-- From nobody Mon Oct 7 07:05: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 88198120072 for ; Sun, 6 Oct 2019 12:07:00 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEnv5lQ9izf1 for ; Sun, 6 Oct 2019 12:06:59 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 DCE6E120048 for ; Sun, 6 Oct 2019 12:06:58 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id x3so9891681oig.2 for ; Sun, 06 Oct 2019 12:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=6cBSlD2VFvrxowO62qXJtF4L+IOJeOeTM0Mhmdfh71o=; b=2Pk3Orec4du04nCM6HyiauguVUpnWN28rFaS8zWBw8fRLB9EaOk27M0Y3KAL58NQq5 0yVe0EKmsC7llNpOu9NU1OuzpGhZsOw2xcLsMLxKdjvv1Ld2VcalI9d7b0hKLI8DRfZU /f4EwNcSNDXL9Emh0m+Jw+7GHQvw4Ybfo0ioen9ws16jPNh0NHh5kBy7bMbBKxpy+u62 nzlxuEoqk+V0uxNHsdwr5xNhEdZbeNgra5MGAVKIhSKsJebwx/SMHSy/PSyKdOP1WRjx uQipa/s7/hGKg79tlSBjREF9XcjcGfL0BOVWvvwn+YxT+8aBb+b3emmsaF2tI1sRA3Ym ZfpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=6cBSlD2VFvrxowO62qXJtF4L+IOJeOeTM0Mhmdfh71o=; b=tqY85g3hDo7scq/sup4tAb7SU5Nzh/GxdpZb0v5lCLfcaqtPU7sR+4HOZnR5joXFzh GmVAyiB/8tPjRxUpBmYY0kv7zR+5wXiCuihX+tOxc8ymuGkljglK8BHjZ1oijYEpiR+p i5t1HpHxJOosMu5ZlViTHVa6fmO1relQa0XnI4F7RS7PJPcpdqOVt1TuOysudjFBa4XH 1rKZgXOXLE54NGv0NqQ/Ocx1ONPdjbOMNcoyFUxDd+URP7bjxc+zaFrha2muxN65Agwk ws3hiIOWVptKKUum9rIrSFShHX0taEY5Ii4YUkYvl+FtDFvfPFng7LPpkpFKWAfTLarX XXkA== X-Gm-Message-State: APjAAAXRY8p7Oic5SXPlzoH8NYxN4eO9gUo2kebvyIBfWp6vzizt2vUy Ey4n8gJlmLW/yn08kZmkgxNdYQ== X-Google-Smtp-Source: APXvYqy/9eTUTbzQurLAkhSsCen8UEiZ8O8K1E6aFn/Hgkt51Hsom3/MmD6u7FHYVkTaV+bQ6N3VWA== X-Received: by 2002:aca:58c6:: with SMTP id m189mr14723790oib.50.1570388817901; Sun, 06 Oct 2019 12:06:57 -0700 (PDT) Received: from [10.10.9.27] (cpe-24-243-152-218.rgv.res.rr.com. [24.243.152.218]) by smtp.gmail.com with ESMTPSA id a9sm3682031oie.7.2019.10.06.12.06.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Oct 2019 12:06:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 6 Oct 2019 14:06:55 -0500 Message-Id: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> References: Cc: Vittorio Bertola , ADD Mailing list , Dave Lawrence In-Reply-To: To: Eric Rescorla X-Mailer: iPhone Mail (17A850) Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:05:45 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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: Sun, 06 Oct 2019 19:07:01 -0000 On Oct 5, 2019, at 22:57, Eric Rescorla wrote: > Right. Our position is that DNS filtering is not a long-term viable strate= gy for filtering when the endpoint wishing to do the resolution is adversari= al. Do you think there=E2=80=99s some better strategy, or do you just see this a= s impossible? =46rom what I=E2=80=99ve seen, botnet mitigation is always an= adaptive strategy, and information collection and pattern recognition are k= ey. So sure, dns filtering is not going to work automatically. But it is an a= ttack surface to use against botnets and is useful as part of a larger strat= egy.=20= From nobody Mon Oct 7 07:05: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 E048C1200CE for ; Sun, 6 Oct 2019 14:29: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5GtGTJ7Y3bl for ; Sun, 6 Oct 2019 14:29:30 -0700 (PDT) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 1881012003E for ; Sun, 6 Oct 2019 14:29:29 -0700 (PDT) Received: by mail-oi1-x242.google.com with SMTP id a15so3994807oic.0 for ; Sun, 06 Oct 2019 14:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zmKf118hodmmDRzHkQi+oB5edj19NKwmP7E4VrJX7ew=; b=AApH4KwPvvQTunUSwQPHp0QKntiYFr5Ua1yhhoPPfUyLvpDUQu1XJQjTnQvb5T3JoV S6uNKx73pj12OqY+VesPCZ77p/2Ojikk1BTH/79DNZe5gUUnKKnd/znQ1cmQ1FnXa5eS H6F0Fh3X0rskL30kEl8r7i2TTyfp+Kddw2yD7xCsmz/kZRrcKotXH+8dPKYTtZg2Caz0 ml5eU9BNHKYssfbtwsTBM/E9wPcRzOeBQ7P98bqJdgDd5rO3HoAYTBNKR2zrpymCAYie pMGS9iroDvvtyu77NXKzktWA0SE9mbfkYtxDfU3Nz/mII0OFEl8omKYN0MVvsPeikAaP jP2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zmKf118hodmmDRzHkQi+oB5edj19NKwmP7E4VrJX7ew=; b=R9q5NLMuf+fUxtmAQCDhuqT11Th4XrJ5WPXF6mg0smJi7CGQIsWaaVaFEK031ERWPQ 1yC9C089YbggVIPB8Tsy1X143PX9Q+wvS7PWUHjwCkvN20G//HREp6B0WX6FeJo3P1YI 0e9cS/+nLDUmRcuXXVzv8+LuRIMHBIcdjFmMfrSqBVqmFZQpsB14P02pnicz2elzvYps 4ST7RVN32i6c5/Z0342/Ljq+w5Ozh2epBX+EtcOlajE/Qz6EiOVZU3g/yYCVJY3OC2G4 4tc390LenGAjfnQpSRg4sD2TSvbl/AOK9oXos//2AEDjarkrqnq9sGUgGzByvoKyAlho c8Xg== X-Gm-Message-State: APjAAAXattTtDE/AhDe9YXUWw371xnuEmQ6dczBI+yb8rOXUU8Qwxo1R 84B9rnf2/S6Ezo00I43a2jaw6g== X-Google-Smtp-Source: APXvYqy9NP8Gq6GTELbJhKdVekTpECPIbtZE4uw8s5vcOG9F7pspSpIqIYeDv/xrTQHwtfuknPSHig== X-Received: by 2002:a54:4f8a:: with SMTP id g10mr15874696oiy.147.1570397369202; Sun, 06 Oct 2019 14:29:29 -0700 (PDT) Received: from [10.10.9.60] (cpe-24-243-152-218.rgv.res.rr.com. [24.243.152.218]) by smtp.gmail.com with ESMTPSA id j31sm3877545ota.13.2019.10.06.14.29.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Oct 2019 14:29:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\)) From: Ted Lemon In-Reply-To: Date: Sun, 6 Oct 2019 14:29:26 -0700 Cc: Vittorio Bertola , ADD Mailing list , Dave Lawrence Content-Transfer-Encoding: quoted-printable Message-Id: <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3600) Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:05:45 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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: Sun, 06 Oct 2019 21:29:32 -0000 On Oct 6, 2019, at 12:30 PM, Eric Rescorla wrote: > As everything moves to being encrypted, generally strategies based on = examining the plaintext of messages in the network will become less = effective. This is one such mechanism. This is not actually true, because at some point there is an endpoint = that sees the cleartext, and if that endpoint isn=E2=80=99t controlled = by the botnet, then there=E2=80=99s an opportunity to intervene. Even = if it is in the control of the botnet, if an intermediary is being used = (as in the Obliviated DNS proposal that was recently mentioned here) = traffic analysis can produce useful intelligence and that intelligence = can be used to block connections. Why do you think botnets bother to = use DNS to find C&C controllers, even though DNS has been being used as = a way to mitigate malware for years? If they could do it some other = way, wouldn=E2=80=99t they have done so? From nobody Mon Oct 7 07:06:24 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 20E1B1200B7 for ; Mon, 7 Oct 2019 02:51: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_HELO_NONE=0.001, 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 BlwS6edG5F-R for ; Mon, 7 Oct 2019 02:51:40 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 213201200C4 for ; Mon, 7 Oct 2019 02:51:39 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id c6so27019242ioo.13 for ; Mon, 07 Oct 2019 02:51: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=8f+bX1+2tKAQD378VF0vtYL96J8xUxKRc69fiyEmMFM=; b=iQnSfHFRWneVrR7UaQuhZuC/dOVc2ZDykXPzaANx3IaK2K61eXMEVO68LclZkFXpg5 L85BSUK++jIYFEBS1vxcECpIqv01zwmUICP9q0CponhqUs1EMTMjJS/FxX3K6k1YSbZ/ 3EsbIZYgRHz5pBHZbLx8m03ajcGOFWUJ56piJBkAbHvouzLnngdVfVaFZWt0uFlNsXD5 U+ffpZZq52lrD/NjqBoToc4JMsXFoSLxuuRkiEHTqfBZUpRojgwR/ssWA/YaxzO8IvwL yNWBNgU2Q1DV7SV97Q52QaFu6DXzyHTTClBuFgLmIaBI9ho4/Xp0b7Gg1AjjcTqQFi65 bNCg== 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=8f+bX1+2tKAQD378VF0vtYL96J8xUxKRc69fiyEmMFM=; b=RBsJk/JwL/2qGuJUjTdiCNFAISfF9LVChYJOUyYB/nq3DnqcpPfVyRV+JUK2DUa5Ko 8ms4bksdhsunKNMs0Jbx4saAyVHa4z5qKZiUm4xx7h5YaT8KoV1tUYcWMIgWiThpyPZ3 syftEjD6AdHRIaFkBrz6i0jt4ptPJWPsH65aF4lXs6AbmPxAVCzHDwyXbTQbBBQlVIdv NA/CChHY7onj5LdniT9lc561jfKPSQtyB1U4037xtVXN8ix0dSaCiC0N3BSzumv5pPpU UZSgsR9cAaclXnqXqnorhUhEXFpSn2NIKwlPpNqLznJoPBZuBChqHwuUTDBawZ7CcaIh emBA== X-Gm-Message-State: APjAAAVWsX1OoNjX160g/iGpAnx3hTYqnRG8NSLTb5lBgm2D2t79MDM8 tGyjA09xS/kUDmsUaHCv3nX1WYZIVIScEDi5bQBMEhc1 X-Google-Smtp-Source: APXvYqymMqHwvksZCY7MpRhesVJQYpZFXqGb5/C4JFu0qTjOGt5lBVWfV7AQHuyNQhkx+ephGR8tGuNDleaqoW70ccE= X-Received: by 2002:a6b:7a05:: with SMTP id h5mr23072826iom.32.1570441899128; Mon, 07 Oct 2019 02:51:39 -0700 (PDT) MIME-Version: 1.0 References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> In-Reply-To: From: tirumal reddy Date: Mon, 7 Oct 2019 15:21:26 +0530 Message-ID: To: Paul Wouters Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000089baae05944eff11" Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:06:22 -0700 Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 07 Oct 2019 09:51:42 -0000 --00000000000089baae05944eff11 Content-Type: text/plain; charset="UTF-8" Hi Paul, Please see inline On Sat, 5 Oct 2019 at 23:28, Paul Wouters wrote: > On Sat, 5 Oct 2019, tirumal reddy wrote: > > > We have published > https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that > discusses a mechanism for the > > DNS server to communicate its cryptographically signed privacy policy > information to a DNS client. By evaluating the DNS > > privacy policy and the signatory, the DNS client can choose to select > or avoid a DoT/DoH server if it doesn't comply with > > the client's privacy expectations. > > Section 10 Security Considerations describes well why I think this is > not a good idea. Publishing a privacy policy in a computer consumable > way has no relationship to the actual DNS server's privacy policy > used. > No, the privacy policy also conveys a URL that points to the human readable privacy policy formation of the DNS server. Public DNS resolvers have published privacy policy statements (for example, see https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/). If a firm violates the privacy claims, it will most likely face penalty (similar to FTC imposing fine on facebook). > > This is not a technical wire problem to solve with an RFC. It is a > social-economic issue. Can we trust vendor X? And vendor X making > claims in JSON about this isn't useful from a technical point of > view, no matter how or where and with what such statements are > (self)signed. > Not really, you probably missed the privacy consideration section. User consent is mandatory to use the discovered DoT/DoH servers, the section says the following: Users are expected to indicate to their system in some way that they trust certain PAT signers (e.g., if working for Example, Inc., the user's system is configured to trust example.com signing the PAT). Separately, the user is expected to indicate to their system their PAT privacy requirements (e.g., logging, etc.). By doing so, thee DNS client can automatically discover local DNS-over-TLS or DNS-over- HTTPS server, validate the PAT signature and check if the PAT complies with user's privacy needs, prior to using that DNS-over-TLS or DNS-over-HTTPS server for DNS queries. Cheers, -Tiru > It's a great topic for consumer advocay organisations, the EFF or > ACLU or EU commisioners. I do not think this is a technical problem > needing a technical standard from the IETF. And any automated > consumption of this leading to changed DNS client behaviour would > be dangerous. > > Paul > --00000000000089baae05944eff11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Please see in= line

On Sat, 5 Oct 2019 at 23:28, Paul Wouters <paul@nohats.ca> wrote:
On Sat, 5 Oct 2019, tirumal = reddy wrote:

> We have published=C2=A0h= ttps://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00= =C2=A0that discusses a mechanism for the
> DNS server to communicate its cryptographically signed privacy policy = information to a DNS client. By evaluating the DNS
> privacy policy and the signatory, the DNS client can choose to =C2=A0s= elect or avoid a DoT/DoH server if it doesn't comply with
> the client's privacy expectations.

Section 10 Security Considerations describes well why I think this is
not a good idea. Publishing a privacy policy in a computer consumable
way has no relationship to the actual DNS server's privacy policy
used.

No, the privacy policy also conve= ys=C2=A0a URL that poi= nts to the human readable privacy policy formation of=C2=A0the DNS server.=C2=A0Pub= lic DNS resolvers have published privacy policy statements (for example, se= e https://developers.cloudflare.= com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/). If a firm v= iolates the privacy claims, it will most likely face penalty (similar to FT= C imposing fine on facebook).=C2=A0
=C2=A0

This is not a technical wire problem to solve with an RFC. It is a
social-economic issue. Can we trust vendor X? And vendor X making
claims in JSON about this isn't useful from a technical point of
view, no matter how or where and with what such statements are
(self)signed.

Not really, you probably = missed the privacy consideration section. User consent is mandatory to use = the discovered DoT/DoH servers, the section says the following:
<= br>
   Users are expected to indicate=
 to their system in some way that they
   trust certain PAT signers (e.g., if working for Example, Inc., the
   user's system is configured to trust example.com signing the PAT).
   Separately, the user is expected to indicate to their system their
   PAT privacy requirements (e.g., logging, etc.).  By doing so, thee DNS
   client can automatically discover local DNS-over-TLS or DNS-over-
   HTTPS server, validate the PAT signature and check if the PAT
   complies with user's privacy needs, prior to using that DNS-over-TLS
   or DNS-over-HTTPS server for DNS queries. 

Cheers,
-Tiru
=C2=A0

It's a great topic for consumer advocay organisations, the EFF or
ACLU or EU commisioners. I do not think this is a technical problem
needing a technical standard from the IETF. And any automated
consumption of this leading to changed DNS client behaviour would
be dangerous.

Paul
--00000000000089baae05944eff11-- From nobody Mon Oct 7 07:06: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 B575712007C for ; Mon, 7 Oct 2019 05:25: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, SPF_HELO_NONE=0.001, 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 h9qFTGnk37GD for ; Mon, 7 Oct 2019 05:25:24 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80B312004E for ; Mon, 7 Oct 2019 05:25:23 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [80.233.45.41]) by relay.sandelman.ca (Postfix) with ESMTPS id 2FCBF1F456; Mon, 7 Oct 2019 12:25:21 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 6CFDE2B03; Mon, 7 Oct 2019 11:58:19 +0200 (CEST) From: Michael Richardson To: ADD Mailing list cc: Paul Wouters In-reply-to: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> Comments: In-reply-to Paul Wouters message dated "Sat, 05 Oct 2019 13:58:01 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 07 Oct 2019 11:58:19 +0200 Message-ID: <28989.1570442299@dooku.sandelman.ca> Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:06:46 -0700 Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 07 Oct 2019 12:25:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> We have >> published=C2=A0https://tools.ietf.org/html/draft-reddy-dprive-dprive= -privacy-policy-00=C2=A0that >> discusses a mechanism for the DNS server to communicate its >> cryptographically signed privacy policy information to a DNS >> client. By evaluating the DNS privacy policy and the signatory, the >> DNS client can choose to =C2=A0select or avoid a DoT/DoH server if it >> doesn't comply with the client's privacy expectations. > Section 10 Security Considerations describes well why I think this is > not a good idea. Publishing a privacy policy in a computer consumable > way has no relationship to the actual DNS server's privacy policy use= d. > This is not a technical wire problem to solve with an RFC. It is a > social-economic issue. Can we trust vendor X? And vendor X making > claims in JSON about this isn't useful from a technical point of view, > no matter how or where and with what such statements are (self)signed. Of course vendor X probably can't say anything trust-worthy about itself. Depending upon one's relationship with X one may be in a position to believe statements from it and take appropriate action. For instance, if X is your employer and your BYOD is paying attention to this statement, then you might decide to refrain from visiting NSFW site FOO. Or decide to use LTE. But, we anticipate that vendor X would have the implementation of their policy reviewed regularly by some other endorser Y. We have been in contact with a few entities that have done these kinds of reviews of DoT systems in the past, but at this point I don't think we have a shared understanding of goals yet.=20 Section 6... The PAT is cryptographically signed by the domain hosting the DNS server and OPTIONALLY BY A THIRD PARTY WHO PERFORMED PRIVACY AND SECURITY AUDIT OF THE DNS SERVER. The privacy policy information will be attested using "Organization Validation" (OV) or "Extended Validation" (EV) certificates to avoid bad actors taking advantage of this mechanism to advertise DNS-over-TLS and DNS-over-HTTPS servers for illegitimate and fraudulent purposes meant to trick DNS clients into believing that they are using a legitimate DNS-over-TLS or DNS- over-HTTPS server hosted to provide privacy for DNS transactions. Alternatively, the DNS client will have to be configured to trust the leaf of the signer of the PAT object. That is, trust of the signer MUST NOT be determined by validating the signer via the OS or browser trust chain because that would allow any arbitrary entity to operate a DNS server and assert any sort of privacy policy. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2bDDsACgkQlUzhVv38 QpB7Ewf+M9TZMwrxIQwQICWwgnZICHA8G+ilhmsv65fLe4Zmli0LzPNnCQkD9rs/ 2UyP+C5LBNRAb4QPOBcYE9eiPnEM4lOWWE4ANPP4kyAdTL7XucHpCA99rR5YM3Cb BVGPIbm15mxlMabXESlk6UU2bg0s5NkEGxGABEl8KxGZRthspqZAAqto8nnLpyTE YSOItuEi6HsN+24Qw7PdgP0AiAPavgjwUAD9dqzEqco2vM5zFD1E+dGzS4cZyZRG kdy/fVa9OzNniSHei2/Age7LO2ZwHCwLdPSwPT5z0GeHRcE3WYWQg5PziDUMCDiX 44O8yfATFk6StfOWLm4aVkEEZ1QJdA== =0OWG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 7 07:07:24 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 437D612008F for ; Mon, 7 Oct 2019 06:32: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, SPF_HELO_NONE=0.001, SPF_NONE=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 5e-VLDuALvjn for ; Mon, 7 Oct 2019 06:32:42 -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 DDF62120020 for ; Mon, 7 Oct 2019 06:32:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46n1ck2Y82zFCK; Mon, 7 Oct 2019 15:32:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570455158; bh=NjGreL+41MKiFPGh3AmJ3iYR0/CVDPXGMQZYsjnYwoE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SP1tlisuDwbvUlbBsXho0+vRkCM6/9xjxBCS9YxETBp5HE2p+BqcnULgNqgFe2OYu QhVSU8RGlL9NbuHnVn9WyIa+T9ERVFdRh0mLvGZ6U1qPMplfl3Bl0xeT4YxK5yWpVX qu1bx4xpg+WpGrFrKUSVGy/qZ3YwNGov1N/hDCjs= 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 bK9qyCePOSND; Mon, 7 Oct 2019 15:32:36 +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; Mon, 7 Oct 2019 15:32:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 876767D8; Mon, 7 Oct 2019 09:32:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 876767D8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7E25B406CB04; Mon, 7 Oct 2019 09:32:34 -0400 (EDT) Date: Mon, 7 Oct 2019 09:32:34 -0400 (EDT) From: Paul Wouters To: tirumal reddy cc: ADD Mailing list In-Reply-To: Message-ID: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 07:07:23 -0700 Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 07 Oct 2019 13:32:44 -0000 On Mon, 7 Oct 2019, tirumal reddy wrote: > Section 10 Security Considerations describes well why I think this is > not a good idea. Publishing a privacy policy in a computer consumable > way has no relationship to the actual DNS server's privacy policy > used. > > No, the privacy policy also conveys a URL that points to the human readable privacy policy formation of the DNS > server. Public DNS resolvers have published privacy policy statements (for example, see > https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/). If a firm violates the privacy > claims, it will most likely face penalty (similar to FTC imposing fine on facebook).  How and how would any enforcement system work for a variety of DNS providers all over the world? ISPs? hotels? coffeeshops? Mobile providers? Will there be an industry standard org? How will this not devolve into government sanctioned mandatory DNS providers on my mobile device? > This is not a technical wire problem to solve with an RFC. It is a > social-economic issue. Can we trust vendor X? And vendor X making > claims in JSON about this isn't useful from a technical point of > view, no matter how or where and with what such statements are > (self)signed. > > Not really, you probably missed the privacy consideration section. User consent is mandatory to use the discovered DoT/DoH > servers, the section says the following: How would that not become another "we use cookies, are you okay" screen for which I have no choice but to say "yes"? > Users are expected to indicate to their system in some way that they > trust certain PAT signers (e.g., if working for Example, Inc., the > user's system is configured to trust example.com signing the PAT). How is that done on my iphone? If I install vendor X application, I already have to trust them (and google or android, etc). Another screen of "terms and services" the enduser is forced to scroll through? > Separately, the user is expected to indicate to their system their > PAT privacy requirements (e.g., logging, etc.). By doing so, thee DNS > client can automatically discover local DNS-over-TLS or DNS-over- > HTTPS server, validate the PAT signature and check if the PAT > complies with user's privacy needs, prior to using that DNS-over-TLS > or DNS-over-HTTPS server for DNS queries. All of these things come down to one thing. Do you trust the DNS provider or not. It's really a binary decision. Dividing this up in a dozen options isn't helping the average user. > It's a great topic for consumer advocay organisations, the EFF or > ACLU or EU commisioners. I do not think this is a technical problem > needing a technical standard from the IETF. And any automated > consumption of this leading to changed DNS client behaviour would > be dangerous. I'm still not convinced this statement is wrong. And additionally can see some serious harmful effects into mandatory censorship if this kind of system becomes mandatory on people's devices. Paul From nobody Mon Oct 7 08:33: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 50B2912003F for ; Mon, 7 Oct 2019 07:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, 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 uaN4lA4-3CWs for ; Mon, 7 Oct 2019 07:53:20 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E9A120041 for ; Mon, 7 Oct 2019 07:53:20 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [80.233.51.189]) by relay.sandelman.ca (Postfix) with ESMTPS id 120721F456 for ; Mon, 7 Oct 2019 14:53:18 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 951BB2A6D; Mon, 7 Oct 2019 16:54:03 +0200 (CEST) From: Michael Richardson To: ADD Mailing list In-reply-to: <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> Comments: In-reply-to Ted Lemon message dated "Sun, 06 Oct 2019 14:29:26 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 07 Oct 2019 16:54:03 +0200 Message-ID: <9161.1570460043@dooku.sandelman.ca> Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 08:33:13 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 07 Oct 2019 14:53:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > This is not actually true, because at some point there is an endpoint > that sees the cleartext, and if that endpoint isn=E2=80=99t controlle= d by the > botnet, then there=E2=80=99s an opportunity to intervene. Even if it= is in the > control of the botnet, if an intermediary is being used (as in the > Obliviated DNS proposal that was recently mentioned here) traffic > analysis can produce useful intelligence and that intelligence can be > used to block connections. Why do you think botnets bother to use D= NS > to find C&C controllers, even though DNS has been being used as a way > to mitigate malware for years? If they could do it some other way, > wouldn=E2=80=99t they have done so? My understanding is that there has been lots of malware that used embedded = IP addresses, but they are less succesful. The layer of indirection that DNS provides allows them to scale their C&C and make it resilient. (Surprise, that's why the rest of us it...) Using names also lets them travel through system configured HTTP proxies. There are still many "enterprises" that have only HTTP alg-proxies as their "firewall", and no default route, for instance. In my experience, such places tend to be very ripe pickings, because they are overconfident in the= ir "firewall"=20 Apparently quite a number of bots also attempt to resolve a few canary domains that should not resolve, and if they do return answers, assume that they are being observed, and stop. Quite a few botnets have been shutdown = by simply registering the canary domain!.. If only the botnet guys would use DNSSEC instead. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2bUYsACgkQlUzhVv38 QpAG4Qf/RnPST2ORYHhCQXkqG0NPWLEejKfjAyCbpeeA27nLdjH9dIUat/83ZrgY lOvWG+/277w67Mew/A7P4qiMF+B1dTjlLXcB7NkGBFyEm3diHdpaEDPas/WJwSIm zROaJu/UlucZz4WwAI7Lgv7sN6vcwuHrA8bIwdw0wBhHFuj0xZlpYFSeD8PIvEXt VrTugh3WoxFbeIlnddBNBTCdhF4f9qnuiACrilnZ6s7eD8f7nzKe2ghgQKmtK6La qMFerw9RF3q7v6ZpCjpenLnO3UvANIdq/WewA/2F9eZNerH611DZM/MUFBYtft6d 39xVIH739yzOkqVObGJCqM2RB2/pUg== =c6Pg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 7 08:33: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 82C98120041 for ; Mon, 7 Oct 2019 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, 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 ym62vRYJrWib for ; Mon, 7 Oct 2019 07:55:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6F912003F for ; Mon, 7 Oct 2019 07:55:54 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [80.233.40.174]) by relay.sandelman.ca (Postfix) with ESMTPS id 85DA41F456 for ; Mon, 7 Oct 2019 14:55:53 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 90D54773; Mon, 7 Oct 2019 16:56:40 +0200 (CEST) From: Michael Richardson To: ADD Mailing list In-reply-to: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> Comments: In-reply-to Paul Wouters message dated "Mon, 07 Oct 2019 09:32:34 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 07 Oct 2019 16:56:40 +0200 Message-ID: <9331.1570460200@dooku.sandelman.ca> Archived-At: X-Mailman-Approved-At: Mon, 07 Oct 2019 08:33:29 -0700 Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 07 Oct 2019 14:55:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > All of these things come down to one thing. Do you trust the DNS > provider or not. It's really a binary decision. Dividing this up > in a dozen options isn't helping the average user. The purpose of this system is to unambiguously (and cryptographically) identify the DNS provider for you, so that if you are an informed user, you can make that binary decision. Who will sign? That's definitely a layer-8 problem, but it still needs to = be solved. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2bUigACgkQlUzhVv38 QpDaygf7BHPMC6aOTWlPTBbBtWWly2mvOZrgRAawreMEMEhQQbwdf26nNZG88yVZ 4p6bkFVChm2HK/CKnVwUvQMLfa8vLKO4JfjpAlO0eNfGysEVI6yOyWIb8jz1jOzo 14e25SwN1pPHZy7KaA93tvzAP210k7bdOucbYbEgjkvWGeiZo0JKSW2WPsKSvWnc JxY/OHRsI+NF+gOnnqNY+GVcC1gK3nqlZ7AeW2GcDhTXNI7hUYa2Kj3vLVQUR1KG RAej++9uNSn0FrDS1Q+nj6ItgvoGFEHJ/MJWXhxTapZuRhM1yesDJ7RchZyYD1Tf mUgcAjBEBTNFIzjm3OKZeesvHYquyA== =meBS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 8 08:01: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 CDD1812011C for ; Mon, 7 Oct 2019 12:03:45 -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_HELO_NONE=0.001, 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 03GeA2-zBULa for ; Mon, 7 Oct 2019 12:03:43 -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 8E21212008A for ; Mon, 7 Oct 2019 12:03:43 -0700 (PDT) Received: from localhost (50-201-95-250-static.hfc.comcastbusiness.net [50.201.95.250]) by mail.hardakers.net (Postfix) with ESMTPA id D32EB23BC0; Mon, 7 Oct 2019 12:03:35 -0700 (PDT) From: Wes Hardaker To: Eric Rescorla Cc: Ted Lemon , Vittorio Bertola , ADD Mailing list , Dave Lawrence References: <2125898585.1637.1569846894886@appsuite-gw2.open-xchange.com> <23957.14959.623208.660312@gro.dd.org> <700513473.13270.1570176591381@appsuite-gw2.open-xchange.com> Date: Mon, 07 Oct 2019 12:03:34 -0700 In-Reply-To: (Eric Rescorla's message of "Sat, 5 Oct 2019 20:57:11 -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: X-Mailman-Approved-At: Tue, 08 Oct 2019 08:01:35 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 07 Oct 2019 19:03:46 -0000 Eric Rescorla writes: > On Sat, Oct 5, 2019 at 9:07 AM Ted Lemon wrote: >=20 > On Oct 4, 2019, at 8:30 AM, Eric Rescorla wrote: >=20=20=20=20 > If the owner of the endsystem consents, then DNS filtering is a > viable mechanism, though we don't think it's the best point to do > filtering at, in part because the granularity of filtering is qui= te > coarse (compare, for instance, Safe Browsing, which operates at a= URL > prefix level). >=20 > I completely agree with your appeal to clarity, but that said I wante= d to point > out an assumption embedded here, which makes sense for Mozilla but do= es not make > sense in general. =C2=A0 The assumption is that the thing doing the f= iltering will get > to see the URL. >=20=20=20=20 > This assumption doesn=E2=80=99t hold for the use case most people hav= e been talking about > here: stopping connections to botnet C&C servers. >=20 > Right. Our position is that DNS filtering is not a long-term viable strat= egy for > filtering when the endpoint wishing to do the resolution is > adversarial. Two things:=20 1) I find it interesting that you care at all about filtering itself, as I think Mozilla's primary desire is to offer privacy protected resolution to a resolver that is trustable (which I support whole-heartedly), and the usage of DoH is the best way to accomplish that (which I also thing is a good thing, though I had doubts at first due to the overhead... but the IMC paper proves its not as bad as I was fearing it would be). But... if a resolver safebrowsing.example.com came along, got registered in the TRR list, Mozilla wouldn't object to that right? Or If a TRR actually supported user-configurable browsing "in some way" (where "in some way" could be as proposed in my draft, eg). IE, as long as resolvers state their intentions, they can filter or not as they please to protect the end-user, and (as you've said) the end user selects the one they want. 2) I suspect that some of the push-back comes from the (perfectly valid) stance that "DNS filtering is not a long-term viable strategy" when it's combined with (me:) "IP address based filtering died ages ago", and no one is offering a replacement. Thus, I think most would agree that they'd prefer something different than DNS filtering, but (very sadly) there is no better alternative at the moment. If only a solution existed that could be proposed at the same time as the loss of a moderately-useful control point is removed for good reason. --=20 Wes Hardaker USC/ISI From nobody Wed Oct 9 00:37: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 D5FA11200B1 for ; Tue, 8 Oct 2019 08:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 pYzQdVjchG2e for ; Tue, 8 Oct 2019 08:26:58 -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 CEC5C120096 for ; Tue, 8 Oct 2019 08:26:57 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id v2so37316894iob.10 for ; Tue, 08 Oct 2019 08:26:57 -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=+RIo3VDxXjpPIkIeefCOQHurldSenYjymSjTAOwYFMU=; b=CeJkOCGeksB+FuSuA44HQNFNflm7qq2rkm+n8HE33w7flLI83oeGL7bgQ6RKhD4Jti 5KoNN44bXULivvbZAbAp2Z0oX9JUzWGkoaDz5jCOXfQvkgWZwsu8paT6df0aBjCdWCp7 c+89jQ/n+RLejKzCa+ky3EgwDJn8mxFPSx4hwyhCvQgtA/rPAy3fn+oNXBQONtb8evO+ mSDAZhUkjfUYS9+EOLULJ5qENUAzGF6qA5NFXlclmSaftU91nZ8xD+CJhxxYbcQ4Kcpf rmdWO/NB5dqo7B8Ma26qrkzUDfiNW6V0Ue4EtrGLJYZ0aM0YprzNlKevK8tvl5qJJGf1 dxVw== 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=+RIo3VDxXjpPIkIeefCOQHurldSenYjymSjTAOwYFMU=; b=KzackobEQHUMzUcdDIjmuVEphts7MKCmAFHvMmgoeB8EokA1Ip8F8aKygcXsnoq914 wvd642EJ1uac+UVdN/jYArAis5cx2sQURIEabAWsNUyBMN4RjKJTFIc1t6EDIw2JO8uP LjzR0SCeoMfkK0AxfsAYM3cSbRWL+SvYct6ofZdb34ljnYlr91aaBW2yDQvtqbDgt4t7 SkbZL7NYHHva39lcVF8y3ku0ApvZr3vkgkz6zXxfHny1/30ItIb4x1csslohcicQf78H ZMZ6W5HZrg9yV5vU5rd1L0ADslOprzy/qkgVxrveISxhlvLGW3n36NJd3AbH1lhvhSw+ W/tw== X-Gm-Message-State: APjAAAXeChG4Zgzu+3tE04tB8tmpL2uD50vrAmVz3HSwJRqWp2hQUaB6 NJG5YNkcA4p9Fie5bUEQMFRg2CoMp6AeNNrvUWu2Tcl7tjY= X-Google-Smtp-Source: APXvYqzAQW7LTFPYyeN8INt7qM1Xc2nG6hmRkDTRJLJ9SPi3vHjG7BTUCWKom9wnzFnoIM8ElsAI5lh8R/MeiBDMDk0= X-Received: by 2002:a05:6638:294:: with SMTP id c20mr32511147jaq.77.1570548417033; Tue, 08 Oct 2019 08:26:57 -0700 (PDT) MIME-Version: 1.0 References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> In-Reply-To: From: tirumal reddy Date: Tue, 8 Oct 2019 16:26:45 +0100 Message-ID: To: Paul Wouters Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007ff90e059467cc2a" Archived-At: X-Mailman-Approved-At: Wed, 09 Oct 2019 00:36:59 -0700 Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 08 Oct 2019 15:27:01 -0000 --0000000000007ff90e059467cc2a Content-Type: text/plain; charset="UTF-8" On Mon, 7 Oct 2019 at 14:32, Paul Wouters wrote: > On Mon, 7 Oct 2019, tirumal reddy wrote: > > > Section 10 Security Considerations describes well why I think this > is > > not a good idea. Publishing a privacy policy in a computer > consumable > > way has no relationship to the actual DNS server's privacy policy > > used. > > > > No, the privacy policy also conveys a URL that points to the human > readable privacy policy formation of the DNS > > server. Public DNS resolvers have published privacy policy statements > (for example, see > > > https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/). > If a firm violates the privacy > > claims, it will most likely face penalty (similar to FTC imposing fine > on facebook). > > How and how would any enforcement system work for a variety of DNS > providers all over the world? ISPs? hotels? coffeeshops? Mobile > providers? Will there be an industry standard org? How will this > not devolve into government sanctioned mandatory DNS providers on > my mobile device? > Users may or may not trust the attached network and the DNS server provided by the network (e.g, a public network). It is similar to the way users disable VPN in specific trusted networks (e.g., Enterprise network) and VPN is enabled by default in all other networks. > > This is not a technical wire problem to solve with an RFC. It is a > > social-economic issue. Can we trust vendor X? And vendor X making > > claims in JSON about this isn't useful from a technical point of > > view, no matter how or where and with what such statements are > > (self)signed. > > > > Not really, you probably missed the privacy consideration section. User > consent is mandatory to use the discovered DoT/DoH > > servers, the section says the following: > > How would that not become another "we use cookies, are you okay" screen > for which I have no choice but to say "yes"? > No. If the privacy requirements of the endpoint are not met, the DNS client can discard using the discovered DNS server in the attached network, and connect to a public DNS resolver meeting the endpoint privacy preserving data policy requirements. The proposed mechanism also helps the DNS client to automatically learn updates to the privacy claims by a DNS server and avoids the need for users to periodically manually review the privacy statement. > > > Users are expected to indicate to their system in some way that they > > trust certain PAT signers (e.g., if working for Example, Inc., the > > user's system is configured to trust example.com signing the PAT). > > How is that done on my iphone? If I install vendor X application, I > already have to trust them (and google or android, etc). Another screen > of "terms and services" the enduser is forced to scroll through? > > > Separately, the user is expected to indicate to their system their > > PAT privacy requirements (e.g., logging, etc.). By doing so, thee DNS > > client can automatically discover local DNS-over-TLS or DNS-over- > > HTTPS server, validate the PAT signature and check if the PAT > > complies with user's privacy needs, prior to using that DNS-over-TLS > > or DNS-over-HTTPS server for DNS queries. > > All of these things come down to one thing. Do you trust the DNS > provider or not. It's really a binary decision. Dividing this up > in a dozen options isn't helping the average user. > The privacy policy information helps make the decision whether the DNS provider can be trusted or not. > > > It's a great topic for consumer advocay organisations, the EFF or > > ACLU or EU commisioners. I do not think this is a technical problem > > needing a technical standard from the IETF. And any automated > > consumption of this leading to changed DNS client behaviour would > > be dangerous. > > I'm still not convinced this statement is wrong. And additionally can > see some serious harmful effects into mandatory censorship if this kind > of system becomes mandatory on people's devices. > I disagree, the proposal helps the user to choose a DNS server that best supports the desired privacy policies. DNS clients do not need to fallback to clear text DNS, and can use the DoT/DoH server provided by the local network. Further, it also provides a mechanism to securely signal to the DNS client that the attached network performs DNS filtering. Cheers, -Tiru > Paul > --0000000000007ff90e059467cc2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 7 Oct 2019 at 14:32, Paul Wouters= <paul@nohats.ca> wrote:
On Mon, 7 Oct 2019, tirumal reddy wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 10 Security Considerations describes= well why I think this is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not a good idea. Publishing a privacy policy= in a computer consumable
>=C2=A0 =C2=A0 =C2=A0 =C2=A0way has no relationship to the actual DNS se= rver's privacy policy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used.
>
> No, the privacy policy also conveys=C2=A0a URL that points to the huma= n readable privacy policy formation of=C2=A0the DNS
> server.=C2=A0Public DNS resolvers have published privacy policy statem= ents (for example, see
> https://= developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/fire= fox/). If a firm violates the privacy
> claims, it will most likely face penalty (similar to FTC imposing fine= on facebook).=C2=A0

How and how would any enforcement system work for a variety of DNS
providers all over the world? ISPs? hotels? coffeeshops? Mobile
providers? Will there be an industry standard org? How will this
not devolve into government sanctioned mandatory DNS providers on
my mobile device?

Users may or may not = trust the attached network and the DNS server provided by the network (e.g,= a public network). It is similar to the way users disable VPN in specific = trusted networks (e.g., Enterprise network) and VPN is enabled by default i= n all other networks.=C2=A0=C2=A0


>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is not a technical wire problem to solv= e with an RFC. It is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0social-economic issue. Can we trust vendor X= ? And vendor X making
>=C2=A0 =C2=A0 =C2=A0 =C2=A0claims in JSON about this isn't useful f= rom a technical point of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0view, no matter how or where and with what s= uch statements are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(self)signed.
>
> Not really, you probably missed the privacy consideration section. Use= r consent is mandatory to use the discovered DoT/DoH
> servers, the section says the following:

How would that not become another "we use cookies, are you okay" = screen for which I have no choice but to say "yes"?

No. If the privacy requirements of the endpoint are = not met, the DNS client can discard using the discovered DNS server in the = attached network, and connect to a public DNS resolver meeting the endpoint= =C2=A0privacy preserving data policy requirements.=C2=A0

The proposed mechanism also helps the DNS client to automatically le= arn updates to the privacy claims by a DNS server and avoids the need for u= sers to periodically manually review the privacy statement.=C2=A0
=C2=A0

>=C2=A0 =C2=A0 Users are expected to indicate to their system in some wa= y that they
>=C2=A0 =C2=A0 trust certain PAT signers (e.g., if working for Example, = Inc., the
>=C2=A0 =C2=A0 user's system is configured to trust example.com signing= the PAT).

How is that done on my iphone? If I install vendor X application, I
already have to trust them (and google or android, etc). Another screen
of "terms and services" the enduser is forced to scroll through?<= br>
>=C2=A0 =C2=A0 Separately, the user is expected to indicate to their sys= tem their
>=C2=A0 =C2=A0 PAT privacy requirements (e.g., logging, etc.).=C2=A0 By = doing so, thee DNS
>=C2=A0 =C2=A0 client can automatically discover local DNS-over-TLS or D= NS-over-
>=C2=A0 =C2=A0 HTTPS server, validate the PAT signature and check if the= PAT
>=C2=A0 =C2=A0 complies with user's privacy needs, prior to using th= at DNS-over-TLS
>=C2=A0 =C2=A0 or DNS-over-HTTPS server for DNS queries.

All of these things come down to one thing. Do you trust the DNS
provider or not. It's really a binary decision. Dividing this up
in a dozen options isn't helping the average user.

The=C2=A0privacy policy information helps make the decision whether the DNS provi= der can be trusted or not.=C2=A0
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0It's a great topic for consumer advocay = organisations, the EFF or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ACLU or EU commisioners. I do not think this= is a technical problem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0needing a technical standard from the IETF. = And any automated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consumption of this leading to changed DNS c= lient behaviour would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be dangerous.

I'm still not convinced this statement is wrong. And additionally can see some serious harmful effects into mandatory censorship if this kind
of system becomes mandatory on people's devices.
<= br>
I disagree, the proposal helps the user to choose a DNS serve= r that best supports the desired privacy policies. DNS clients do not need = to fallback to clear text DNS, and can use the DoT/DoH server provided by t= he local network. Further, it also provides a mechanism to securely signal= =20 to the DNS client that the attached network performs DNS filtering.=C2=A0

Cheers,
-Tiru


Paul
--0000000000007ff90e059467cc2a-- From nobody Wed Oct 9 00:37: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 8994A1200E5 for ; Tue, 8 Oct 2019 11:48:19 -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_HELO_NONE=0.001, 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 3cy5xQk6XLdE for ; Tue, 8 Oct 2019 11:48:17 -0700 (PDT) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C421200B9 for ; Tue, 8 Oct 2019 11:48:16 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9530F8D4CB; Tue, 8 Oct 2019 14:48:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23964.55791.591141.356687@gro.dd.org> Date: Tue, 8 Oct 2019 14:48:15 -0400 From: Dave Lawrence To: ADD Mailing list In-Reply-To: <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> Archived-At: X-Mailman-Approved-At: Wed, 09 Oct 2019 00:37:41 -0700 Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 08 Oct 2019 18:48:19 -0000 Ted Lemon writes: > Why do you think botnets bother to use DNS to find C&C controllers, > even though DNS has been being used as a way to mitigate malware for > years=3F If they could do it some other way, wouldn=E2=80=99t they = have done so=3F=20 Certainly one other way of interpreting this state of affairs is that they still do because the mitigations haven't been effective enough. From nobody Wed Oct 9 00:38: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 016EA12008D for ; Wed, 9 Oct 2019 00:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 9HaZ6PM4NDgI for ; Wed, 9 Oct 2019 00:38:51 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 C3D9D120074 for ; Wed, 9 Oct 2019 00:38:51 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id h144so2836647iof.7 for ; Wed, 09 Oct 2019 00:38:51 -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; bh=bPklnEXZkCHHJ7/wYvrW+YzT8MmCaaA/q3sqD2vAyhA=; b=fZLOId8IbBK3XzKvNnCh2q5TsmZqRs4/Tv5y0wAoXvq62N2N7su2pwdxAWPlKnv531 XrRVorYVjfim3jeWjEhj5s5kN2uopqepUN6uBp3rbZnid1bIF9PNTeLZxXxpN25AZrt0 j/w+XX+jU7J98qy+4asEKUorIlpimhRxsPxSUha39Wbl6wmlPbRNOb/LBbLFhjyDRgLc RS0ZF9QYO3SwXiVOHbzvCJXNwX6O6OOwOZsvRs9AXnQS4hUqRPedG5BXQyCMRkWGBVFG YmwZuCNvrLiyGc1/EyzamA3bq92sTkGY8t21JCo+WXqSKT/isVRS1OkioU0UZqOdCMDl MXhA== X-Gm-Message-State: APjAAAXsowNROEmIFTY6uAQop6cf/EeW+QjmZF9R6REjdy0tZoOXO7vU hmGiDRDXpIAWjMpWZ9SAT6XCINRGBTiaZn2mUd47zQKt X-Google-Smtp-Source: APXvYqweKx/IMKEelmjJ/pAaf3eeBW/0/YU7HvDIxgiJOnLbB4lh2C/1cFDl9uekdrjFnkOGcYpYve/1Kr5YDX+/50o= X-Received: by 2002:a92:9892:: with SMTP id a18mr1956765ill.266.1570606730376; Wed, 09 Oct 2019 00:38:50 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Wed, 9 Oct 2019 09:38:37 +0200 Message-ID: To: add@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 07:38:53 -0000 Hi, all, The IESG has worked up a proposal for a possible working group, which we're tentatively calling "ABCD", for "Application Behavior Considering DNS". We can discuss the charter proposal here, and expect to approve a working-group-forming BoF for Singapore. I realize that the charter proposal isn't going to please everyone (and perhaps will please no one), but it's something that, at a first level of review, the IESG accepts and will likely want to move forward with. See the proposal here: https://trac.tools.ietf.org/bof/trac/wiki/WikiStart I am also going to remove the moderation of this list for now. Let's see how that goes. Please continue being calm, thoughtful, and respectful (and thanks for having done that during the moderation period). Barry From nobody Wed Oct 9 00:51: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 CE377120817 for ; Wed, 9 Oct 2019 00:51:44 -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_HELO_NONE=0.001, 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 0KxJBDrAS9pp for ; Wed, 9 Oct 2019 00:51:42 -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 F07E0120178 for ; Wed, 9 Oct 2019 00:51:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8679FBE4C; Wed, 9 Oct 2019 08:51:39 +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 sDj3bw5iwr0n; Wed, 9 Oct 2019 08:51:37 +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 C9963BE51; Wed, 9 Oct 2019 08:51:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1570607497; bh=eh1y+5gIUihOfe61fp/6hWItdUhM5ZX3bqiR1Q4MbPE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZgtB+4UKOgHJV6dSG/GEs0p2yxQX5szarkksPKBEiHQublgM1cTeiNlYBStOs6J6d AZu+ZClQpQrZzedwgZFKNWaLNu7CQ/VSgIx02jEh4B1/nK6ZOwaX7tjb4AxYtJpuDH 8HYGN6GhkEfGwRZfd2RZxAb5L6K4bxJ+wNYUDPUI= To: Barry Leiba , 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: Wed, 9 Oct 2019 08:51:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4SBLsR9CWkUMGZGmYFSxnDOh6WPXJ5DFY" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 07:51:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4SBLsR9CWkUMGZGmYFSxnDOh6WPXJ5DFY Content-Type: multipart/mixed; boundary="cedA0kecYk4bwZg1pk76x4L3CAhoRk8Ae"; protected-headers="v1" From: Stephen Farrell To: Barry Leiba , add@ietf.org Message-ID: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 References: In-Reply-To: --cedA0kecYk4bwZg1pk76x4L3CAhoRk8Ae Content-Type: multipart/mixed; boundary="------------1C17FDB2920837DA2A0E317E" Content-Language: en-GB This is a multi-part message in MIME format. --------------1C17FDB2920837DA2A0E317E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/10/2019 08:38, Barry Leiba wrote: > Hi, all, >=20 > The IESG has worked up a proposal for a possible working group, which > we're tentatively calling "ABCD", for "Application Behavior > Considering DNS". We can discuss the charter proposal here, and > expect to approve a working-group-forming BoF for Singapore. >=20 > I realize that the charter proposal isn't going to please everyone > (and perhaps will please no one), but it's something that, at a first > level of review, the IESG accepts and will likely want to move forward > with. >=20 > See the proposal here: > https://trac.tools.ietf.org/bof/trac/wiki/WikiStart I understand that figuring out what to do here is tricky, but it's unclear to me how that text moves us along at all. I'm also unconvinced that adding a new WG is the right approach. I see two main problems: 1) What is out of scope? The current text seems to leave everything related to DNS privacy and it's impacts as being in scope. So far, having such a broad scope doesn't seem to me to have gone well. 2) "This working group will coordinate with the DNSOP (OPS Area), DPRIVE (INT Area), and DOH (ART area) working groups,..." seems to me to mean that the confusion with proposals and discussions we've seen will continue. Moving from 3 WGs and a non-WG list, to 4 WGs, doesn't seem likely to help that aspect. For a specific example DPRIVE is already working on a BCP that would likely overlap with one of the initial focus areas listed here. That makes no sense to me. Cheers, S. >=20 > I am also going to remove the moderation of this list for now. Let's > see how that goes. Please continue being calm, thoughtful, and > respectful (and thanks for having done that during the moderation > period). >=20 > Barry >=20 --------------1C17FDB2920837DA2A0E317E 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----- --------------1C17FDB2920837DA2A0E317E-- --cedA0kecYk4bwZg1pk76x4L3CAhoRk8Ae-- --4SBLsR9CWkUMGZGmYFSxnDOh6WPXJ5DFY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2dkYgACgkQWrL68XsX K+pOGBAAlhKxi2xfV9B1sD7+oVCC87nBwJDW3QEVTA7RwqCyzS2GniPvBv9FhXJz 0F93WHMwQHazk5xHtNC3AIYTGJU+Y5JkwuGu4gbP/ma2f1d/r0FUI8tJQj4Zb9bb GnAgNQO3ASaVTDOQhCMOXbWDo7j7S7EfX+9OErIr7czRKC7pLpHs5pbpNiY/3Ups 7cJdFADsCL8XAZYZ4P5yPCf1dTL+CG3Dw/ThKHd44iDurZ5W/nAf90iXbr6jWA8d TIQ9MA/eTRg35cogXD/A2lWWt1KiUynDPhYllP/iuePZ7D8+UdRqMoAMdoXK9dmw iYYWgxdY8E7ABusdQ4j3L32bIRsNJ4Ra6CHANGRrd1785CF/W9HpbiNGn6K5bxU3 BCOdgcP8s8d93g7pW5wy7fwYTtVg2mAAKTOXbU9NMcPk4SPcjTc+fmgHdNw65mtz h5lwAYHtZTvuac0akGMImRlV/VhlZt4Luu67tM9TzuTL/oDP03F//OAwtJ9wvlh7 yZUMP9bXsqK4u1wJUsdApMFJPWnKo9rIszVjFejJAOBHoais4ip3xKaIFOKNajlk 3yq2F0Ql6bQVeSKpdaGNdV+R02va7wudlo5N8l3MfqkRa+Z7dW8exmzGQSAfQQN7 +p+qNVyzxdu8OCdYZibVZ08i8BVnoQBAxVDi/qSyhSZivsj9vAs= =HViT -----END PGP SIGNATURE----- --4SBLsR9CWkUMGZGmYFSxnDOh6WPXJ5DFY-- From nobody Wed Oct 9 01:41: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 600BA1200A3 for ; Wed, 9 Oct 2019 01:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 HgNPkwX3OgXS for ; Wed, 9 Oct 2019 01:41:33 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453AD12000F for ; Wed, 9 Oct 2019 01:41:33 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 8D555242141F; Wed, 9 Oct 2019 08:41:30 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Wed, 9 Oct 2019 09:41:29 +0100 Cc: Barry Leiba , add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.com> References: To: Stephen Farrell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 08:41:34 -0000 > On 9 Oct 2019, at 08:51, Stephen Farrell = wrote: >=20 > I see two main problems: >=20 > 1) What is out of scope? The current text seems to leave > everything related to DNS privacy and it's impacts as being > in scope.=20 What aspects of DNS privacy should be out of scope for the proposed WG? At first glance, the proposed charter looks fine. I accept a broadly scoped WG could be awkward. Though what=E2=80=99s = being proposed here seems reasonably well scoped. If the WG has strong = leadership and everyone uses common sense, I think it would work. Famous = last words... BTW, it=E2=80=99s =E2=80=9Cits impact=E2=80=9D. Yes, I need to resign = from the apostrophe police and get out more. :-) > 2) "This working group will coordinate with the DNSOP (OPS > Area), DPRIVE (INT Area), and DOH (ART area) working groups,..." > seems to me to mean that the confusion with proposals and > discussions we've seen will continue. Moving from 3 WGs and > a non-WG list, to 4 WGs, doesn't seem likely to help that > aspect. For a specific example DPRIVE is already working > on a BCP that would likely overlap with one of the initial > focus areas listed here. That makes no sense to me. One possibility for dealing with this overlap could be for the new WG to = look at the deployment and operational considerations surrounding = whatever DNS-privacy-friendly technologies emerge from DPRIVE. I suppose = that could mean the BCP that=E2=80=99s under development moves to the = new WG. One meta-question: would ABCD be in the art area? I think ops might be a = better home for it. From nobody Wed Oct 9 01:55:02 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 BBE391200A3 for ; Wed, 9 Oct 2019 01:55:00 -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_HELO_NONE=0.001, 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 RLxxCmUlIpBa for ; Wed, 9 Oct 2019 01:54:59 -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 0138F120047 for ; Wed, 9 Oct 2019 01:54:58 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id w12so3183263iol.11 for ; Wed, 09 Oct 2019 01:54:58 -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=du0eMFZTaQfoLEivMa4H5kuXwFgL8woIoZWW65OuOSE=; b=n2qvL2pLP4v50zlbYB8LjcN1KnWgyFeMOM81dAa2jkpt83CixPnVGi4tJ242lhSxUt gU1yT4RNkqNcRTOVVfSldeBSls6B1q60Y5Bv8SOCpOZZl8yA0bM2wxzZv8z9DCbLSk4E fF64kIGELlpuGSicXh+981grU+QynLe9cggmWAVn4KllFtjeXwuvZj7vQykVbC5YBvyX AOm+TfzSXumSPD/WNcB97il+QyW8ZF45j+hxL7vT74poYGSzGYAjNPEfmBfLjoDTZFIy qRcRRPIDgbRYs3EzZDEu6QKAYAUCPytf4hvGSDPUJCO/iAivA8LTPNPwN9cmPJcSg647 bsXw== 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=du0eMFZTaQfoLEivMa4H5kuXwFgL8woIoZWW65OuOSE=; b=f5Vx3kvqQJhGRNXicMtMOKvHley8YuQuJ+Tgx3XLloi3kTomER4VQW8ihxms8AVPA6 Di+clmwpiwzOenxTfV4IcQgZMX0uCP3FkzsEoc+o0wUJ/fYDJgNU2yt1WDfWkz97lcjB Fa1bfX658Gzrdp/2QBm8fKAfJlSwyLWaYRAsZU1pagYcHNq40bLDsfVqTijGHWBGy4c5 06dwhvjv7AyZemJ7yqusdEoMFMUOKCkje0gHHZ6yTAMP3xjNrKbI/xtZ++5CQ1YVaZ9w niARMKWnHq81M00lay/KzIb+bmnpK4KGpSfjsKqngT4b1R7T9tl0XtbB7ObS4glNIEoI gcFg== X-Gm-Message-State: APjAAAUJQBZgLfLZbarwTtu68llR6sdT1FbXgVgSc23lpKzu+iaOqKem hXNZoqP5d2pHe66ZNXLd5kdttTrM/piSo/DRx6s= X-Google-Smtp-Source: APXvYqybuq5uttapVkPFaH5X+GasO1meqPelGgztIpm6Lyyu4nsTkDqaTgXXqfhkWIX3X398pXYwuE1gRgTNz8c8Wuo= X-Received: by 2002:a05:6e02:14d:: with SMTP id j13mr2127253ilr.257.1570611298192; Wed, 09 Oct 2019 01:54:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 15:54:47 +0700 Message-ID: To: Barry Leiba Cc: add@ietf.org Content-Type: multipart/alternative; boundary="00000000000082563f05947670d0" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 08:55:01 -0000 --00000000000082563f05947670d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 2:39 PM Barry Leiba wrote: > I realize that the charter proposal isn't going to please everyone > (and perhaps will please no one), but it's something that, at a first > level of review, the IESG accepts and will likely want to move forward > with. Hi, Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 individu= als, rather than a mailing list? The proposed charter looks extremely misguided to me. But a proposal that no one will put their name on doesn=E2=80=99t even deserve an argument. thanks, Rob --00000000000082563f05947670d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 2:39 PM Barry Leiba <barryleiba@computer.org> wrote= :


I realize that the charter proposal isn't going to please everyone
(and perhaps will please no one), but it's something that, at a first level of review, the IESG accepts and will likely want to move forward
with.

Hi,

Who wrote the charter? Shouldn= =E2=80=99t the BoF proponents be 1-3 individuals, rather than a mailing lis= t?

The proposed charter = looks extremely misguided to me. But a proposal that no one will put their = name on doesn=E2=80=99t even deserve an argument.
thanks,
Rob


--00000000000082563f05947670d0-- From nobody Wed Oct 9 02:04: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 E97CF120047 for ; Wed, 9 Oct 2019 02:04:22 -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_HELO_NONE=0.001, 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 wDRitd1xriWF for ; Wed, 9 Oct 2019 02:04:20 -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 A358C120046 for ; Wed, 9 Oct 2019 02:04:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8FD46BE50; Wed, 9 Oct 2019 10:04:17 +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 bYzGdwr6QU0F; Wed, 9 Oct 2019 10:04:17 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4BB9BBE2E; Wed, 9 Oct 2019 10:04:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1570611857; bh=FalkX6FkLPJrbgKA1K4y0BHg1Sh67E716h+P06ICnDU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=2TYtFPkRK335rCvwF7HP9o9y1qpIjjO7itl5L3yuBx0Lhizbc0sMmbHuTCa4MEiJk VcAyzZHEnXu4nzHPdnLMfL658ObhnpxxOkyMQ0tmkdLohULnnO6CgUls+PiteFX2Q1 D44WvJkFzr6tHPfmk297YPB2J9hoAgN5YG7QOgfA= To: Jim Reid Cc: Barry Leiba , add@ietf.org References: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.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: <18b91598-e199-19d1-4a27-c49585fea772@cs.tcd.ie> Date: Wed, 9 Oct 2019 10:04:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Wq32kB30OodhRdoqABbI4FuP79x37CgtM" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 09:04:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wq32kB30OodhRdoqABbI4FuP79x37CgtM Content-Type: multipart/mixed; boundary="jTG9Lxx694X6sNjNyOHtIh38YDKCHzzbq"; protected-headers="v1" From: Stephen Farrell To: Jim Reid Cc: Barry Leiba , add@ietf.org Message-ID: <18b91598-e199-19d1-4a27-c49585fea772@cs.tcd.ie> Subject: Re: [Add] Proposed charter and BoF request for IETF 106 References: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.com> In-Reply-To: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.com> --jTG9Lxx694X6sNjNyOHtIh38YDKCHzzbq Content-Type: multipart/mixed; boundary="------------C7A1DB186449090EC1D2CBBB" Content-Language: en-GB This is a multi-part message in MIME format. --------------C7A1DB186449090EC1D2CBBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/10/2019 09:41, Jim Reid wrote: >=20 >=20 >> On 9 Oct 2019, at 08:51, Stephen Farrell >> wrote: >>=20 >> I see two main problems: >>=20 >> 1) What is out of scope? The current text seems to leave everything >> related to DNS privacy and it's impacts as being in scope. >=20 > What aspects of DNS privacy should be out of scope for the proposed > WG? Based on the current text, I don't know. If we are going to have N WGs in this space, it seems important that we have clarity as to the scope of those. >=20 > At first glance, the proposed charter looks fine. >=20 > I accept a broadly scoped WG could be awkward. Though what=E2=80=99s be= ing > proposed here seems reasonably well scoped. If the WG has strong > leadership and everyone uses common sense, I think it would work. I wonder if common sense and WG chairs are enough to deal with the different perspectives/interests here. > Famous last words... Indeed. > BTW, it=E2=80=99s =E2=80=9Cits impact=E2=80=9D. Yes, I need to resign f= rom the apostrophe > police and get out more. :-) Oops. I depend on you to keep on keeping on improving me:-) >=20 >> 2) "This working group will coordinate with the DNSOP (OPS Area), >> DPRIVE (INT Area), and DOH (ART area) working groups,..." seems to >> me to mean that the confusion with proposals and discussions we've >> seen will continue. Moving from 3 WGs and a non-WG list, to 4 WGs, >> doesn't seem likely to help that aspect. For a specific example >> DPRIVE is already working on a BCP that would likely overlap with >> one of the initial focus areas listed here. That makes no sense to >> me. >=20 > One possibility for dealing with this overlap could be for the new WG > to look at the deployment and operational considerations surrounding > whatever DNS-privacy-friendly technologies emerge from DPRIVE.=20 Meaning it wouldn't develop any new protocol? Not sure that'd work. > I > suppose that could mean the BCP that=E2=80=99s under development moves = to the > new WG. >=20 > One meta-question: would ABCD be in the art area? I think ops might > be a better home for it. That's one for the IESG. I suspect the right answer will be fairly obvious or a "doesn't matter" if/when there's a final charter. If that is not the case, then I'd really wonder if the charter is the right one. Cheers, S. >=20 >=20 --------------C7A1DB186449090EC1D2CBBB 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----- --------------C7A1DB186449090EC1D2CBBB-- --jTG9Lxx694X6sNjNyOHtIh38YDKCHzzbq-- --Wq32kB30OodhRdoqABbI4FuP79x37CgtM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2dopAACgkQWrL68XsX K+qAGg//XDzHpwYGPzkPcW1wzfoZw0eNKUxu1BfjdXP97a5gYLO3N4URWBLmrc4A TMNuLXBsiN65eqhjtf+mEfMN19kCHVDJXWvwUi4MZjTk6wO+HK9PWg3dmN46ftz/ ulbtGobgB9tRVcB6hKG8mK2OpCAnsPbdQ66ryW5f+FlhQ1b2n0rY48CbbyLV2fjX z9h6n3tvFQhiEGI1ET0ox+cIyaeH+aSi0tYUdxDXkUrHbK/UPYl7BX+Yo7NEr/VZ pFr6Ko6guCNHWpwXN3gD0fSSUJ3idycAP6LruEnK7chQdwVgrD9p6if4o8BqMKBJ o81YWBHKjlW33Vi1oYlcCZjfJhWYKBqorRzkoqB9cdGKzoU47N/LiEAiHqKNgXEl fjtonBqOsi6GQFjPx6goDsqcOtd9RgT/QnuyvvnBq5nYbnzFdei1tIqBv2+205dk 0OiEBhLpmE6xUTzooeUlKVvKhho1ul16lbEVz5jwZBf4QQ3Q9Vj0cyhnWdqQJ43s M9xilaGq75rEj14KMJY10o9qbbKSuwa+YK6wxaQ65nhMSJrIhrMVM83zC7BCgF+V BeQsqdfxZuDQ1mCKYcdj43aGQp2NmEaHzR+FYMQy6mvB8cjg4ZCIVBBTtDyFLWyL apTTMIbTMVTGcOgt4ctFKIJIMIalbi7+yLcRbjOrIA3KKPG3muk= =9++y -----END PGP SIGNATURE----- --Wq32kB30OodhRdoqABbI4FuP79x37CgtM-- From nobody Wed Oct 9 04:59: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 DA6061200B7 for ; Wed, 9 Oct 2019 04:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQj2skPAdpOd for ; Wed, 9 Oct 2019 04:59:08 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 8883712008B for ; Wed, 9 Oct 2019 04:59:07 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id x80so1444560lff.3 for ; Wed, 09 Oct 2019 04:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jknOW6G1cymt35Kzedav9USb7QJUIh0yIc27e5IY4zs=; b=c5vvtlGMyuDuj16D0sPZ3SdhELA9O/C1FtWhW28+WZFbfRkdfDAtl8UCpNQI55khU6 W/nRsNDeHkGgnLs3bkogHlM4OBHjPd965+c0fJo3b48tFtFa1QKdiHt5pVsStC/oDX8d XPumxfTVaCd1edFp2Nl01wn5awe08Y2GApAkv8WE4RQlrzLBZbZLMZzJMCeid6lKuVHH cI5DsvifjsSRUTfMwXi1mmCqsGggk75cqdTaKbn/JpMBtqQ4uEYgdzKLAAAoftfgO3FU QuEcuOvY1eJQFBKySu7NcPzg1roS6KSTLwIPGwxCw8y3i6zUn+CpXLRJvmS3meoR/9dp fbjA== 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=jknOW6G1cymt35Kzedav9USb7QJUIh0yIc27e5IY4zs=; b=VLZDvRh8MceMH7U2mqhmwHMPhjFb4TTbIm7lE1gkCQn+xR321jlrNE0OoFnuWtFiL/ TbV0l0h7CZ/SI0FElN033e62huR5b5b13RcQy4cqZYQ9T2CKMOayZALPMOXnxDiD3W07 YES9ZBNiA19Gr906lvYeSSzAGkbiMDY10SG7DR8zyrhNdDl9RPdRH8nLUh3/R6K9o14/ C7qdCiZTNUikzaIXNZIGJCuXek9nSQghpzs1IBoJHJ/HGhcuxr1fqb31luQw0zfbjhYu /Igaiyn4lWPm2ncnFcM+lzbJMUH8rxapki1Z9piivsZl8uz8HVjPnpa+fPyksbl2V9Ue vbOw== X-Gm-Message-State: APjAAAUfs/gyv6xQY2QJAwi3zvCEqi4gEIWe+SWBDD+4PLxsgkQ1xV5q pRd+jHZzHEzL0F3dZq8TpTLV5Iv5f53IVS0rn8E3uQ== X-Google-Smtp-Source: APXvYqzv3XANbOaHym/lx41evfGkVczznxnRSiz/tuvTCkPwNaj3kAxGKsSrRjyCLcqHgfyYp/gK//6ojK7PkSQ0nyQ= X-Received: by 2002:ac2:4a75:: with SMTP id q21mr1826846lfp.94.1570622345563; Wed, 09 Oct 2019 04:59:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 04:58:27 -0700 Message-ID: To: Barry Leiba Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000fbe93c05947902c4" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 11:59:11 -0000 --000000000000fbe93c05947902c4 Content-Type: text/plain; charset="UTF-8" Barry, I took a first look at your proposed ABCD charter. Thanks for proposing something. At a high level, I think there are some good areas for discussion here, but they're going to get swamped by the inclusion of a bunch of contentious topics we're not likely to get resolution on. I think this would be much stronger if it focused entirely on technical matters on which there is at least some agreement, specifically: - Signalling that the network has DoH support, who provides it, and (potentially) what their policies are. - Signaling that the network has some kind of filtering policy that might make the application think twice about using DoH. - Something like the apple proposal that does "steering" of traffic to the right resolver. Note that these mechanisms should generally not tell apps what policies they should follow when they see these signals. These seem to be on your list below. I think we should stay away from anything that is about specifying best current practices because as far as I can tell all but the most trivial ones (here is how to safely run a TLS server or something) are contested. For instance, even retention period has very strong views on both sides. > Together, these developments may represent > a set of shifts depending on how the new protocols are deployed: from > cleartext to encrypted transports; from use of unique port numbers for > DNS resolution to ports that support significant other traffic (e.g., > HTTPS); from network operator control of DNS configuration to control by > clients, third-party resolvers, or others; and from the use of a large, > dispersed set of network operator resolvers to a smaller set of more > centralized resolvers operated by other parties. The word "may" is doing a lot of work here. In particular, while I realize that this centralization argument has been repeatedly raised, it's not really a point of consensus. Consider that in the United States, the ISP market is dominated by a very small number of players, with two companies, Charter and Comcast, having the vast majority of the market ( https://www.statista.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider/ ) Because residential customers generally use the ISP resolver, this market is already highly centralized. It's true that there are a lot of much smaller enterprise resolvers, but every major application-level DNS rollout I have seen proposed attempts to preserve that situation. > This potential set of shifts raises many questions given the long history > and current status of DNS operational practices. Network operators have > historically used DNS services for a variety of purposes beyond simple > query resolution: to mitigate network and security threats, to enforce > enterprise policy, to provide parental controls and other filters, and to > comply with relevant laws and regulations, among others. This list of practices would be much more accurate if it included the resolver-level DNS practices that we are trying to mitigate using DoH, including NXDOMAIN synthesis and collection of user browsing history data. > Achieving these > objectives while providing confidentiality and tamper-resistance will > generally require that network operators shift to one of the available > encrypted transports for their resolvers and that clients include > configuration options to select them. This entirely misses the point, which isn't just to do a lot of encryption but to provide security for the user. Just having network operators transition to secure transports while continuing their current practices does not address the issue. > Specific initial areas of focus include: > > - Resolver discovery > - Expression of resolver policy > - Query routing in the presence of resolver choice > - Best Current Practices for the deployment and operation of encrypted DNS transport This seems like it leaves all of the contested issues firmly in scope. I can't imagine how we're going to get consensus on best current practices, when we can't even agree on the terms for resolver selection. -Ekr On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba wrote: > Hi, all, > > The IESG has worked up a proposal for a possible working group, which > we're tentatively calling "ABCD", for "Application Behavior > Considering DNS". We can discuss the charter proposal here, and > expect to approve a working-group-forming BoF for Singapore. > > I realize that the charter proposal isn't going to please everyone > (and perhaps will please no one), but it's something that, at a first > level of review, the IESG accepts and will likely want to move forward > with. > > See the proposal here: > https://trac.tools.ietf.org/bof/trac/wiki/WikiStart > > I am also going to remove the moderation of this list for now. Let's > see how that goes. Please continue being calm, thoughtful, and > respectful (and thanks for having done that during the moderation > period). > > Barry > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000fbe93c05947902c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Barry,

I took a first look at your proposed ABCD ch= arter. Thanks for
proposing something.

At a high level, I think t= here are some good areas for discussion
here, but they're going to g= et swamped by the inclusion of a bunch of
contentious topics we're n= ot likely to get resolution on.

I think this would be much stronger = if it focused entirely
on technical matters on which there is at least s= ome agreement,
specifically:

- Signalling that the network has Do= H support, who provides it,
=C2=A0 and (potentially) what their policies= are.

- Signaling that the network has some kind of filtering policy=
=C2=A0 that might make the application think twice about using
=C2= =A0 DoH.

- Something like the apple proposal that does "steerin= g" of
=C2=A0 traffic to the right resolver.
=C2=A0
Note that= these mechanisms should generally not tell apps what
policies they shou= ld follow when they see these signals.


These seem to be on your = list below. I think we should stay away from
anything that is about spec= ifying best current practices because as
far as I can tell all but the m= ost trivial ones (here is how to safely
run a TLS server or something) a= re contested. For instance, even
retention period has very strong views = on both sides.


> Together, these developments may represent> a set of shifts depending on how the new protocols are deployed: fro= m
> cleartext to encrypted transports; from use of unique port number= s for
> DNS resolution to ports that support significant other traffi= c (e.g.,
> HTTPS); from network operator control of DNS configuration= to control by
> clients, third-party resolvers, or others; and from = the use of a large,
> dispersed set of network operator resolvers to = a smaller set of more
> centralized resolvers operated by other parti= es.

The word "may" is doing a lot of work here. In particu= lar, while I
realize that this centralization argument has been repeated= ly raised,
it's not really a point of consensus. Consider that in th= e United
States, the ISP market is dominated by a very small number of p= layers,
with two companies, Charter and Comcast, having the vast majorit= y of
the market
(https://www.statist= a.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider= /)
Because residential customers generally use the ISP resolver, thi= s
market is already highly centralized. It's true that there are a l= ot
of much smaller enterprise resolvers, but every major
application-= level DNS rollout I have seen proposed attempts to
preserve that situati= on.



> This potential set of shifts raises many questions = given the long history
> and current status of DNS operational practi= ces. Network operators have
> historically used DNS services for a va= riety of purposes beyond simple
> query resolution: to mitigate netwo= rk and security threats, to enforce
> enterprise policy, to provide p= arental controls and other filters, and to
> comply with relevant law= s and regulations, among others.

This list of practices would be muc= h more accurate if it included the
resolver-level DNS practices that we = are trying to mitigate using DoH,
including NXDOMAIN synthesis and colle= ction of user browsing history
data.


> Achieving these
= > objectives while providing confidentiality and tamper-resistance will<= br>> generally require that network operators shift to one of the availa= ble
> encrypted transports for their resolvers and that clients inclu= de
> configuration options to select them.

This entirely misse= s the point, which isn't just to do a lot of encryption
but to provi= de security for the user. Just having network operators
transition to se= cure transports while continuing their current practices
does not addres= s the issue.


> Specific initial areas of focus include:
&g= t;
> - Resolver discovery
> - Expression of resolver policy> - Query routing in the presence of resolver choice
> - Best Cur= rent Practices for the deployment and operation of encrypted DNS transport<= br>
This seems like it leaves all of the contested issues firmly
in s= cope. I can't imagine how we're going to get consensus on
best c= urrent practices, when we can't even agree on the terms
for resolver= selection.

-Ekr

On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba <= barryleiba@computer.org> = wrote:
Hi, all,<= br>
The IESG has worked up a proposal for a possible working group, which
we're tentatively calling "ABCD", for "Application Behav= ior
Considering DNS".=C2=A0 We can discuss the charter proposal here, and<= br> expect to approve a working-group-forming BoF for Singapore.

I realize that the charter proposal isn't going to please everyone
(and perhaps will please no one), but it's something that, at a first level of review, the IESG accepts and will likely want to move forward
with.

See the proposal here:
=C2=A0 =C2=A0 =C2=A0 https://trac.tools.ietf.org/= bof/trac/wiki/WikiStart

I am also going to remove the moderation of this list for now.=C2=A0 Let= 9;s
see how that goes.=C2=A0 Please continue being calm, thoughtful, and
respectful (and thanks for having done that during the moderation
period).

Barry

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000fbe93c05947902c4-- From nobody Wed Oct 9 06:30: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 529221200F7 for ; Wed, 9 Oct 2019 06:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXmAXpMxTn3W for ; Wed, 9 Oct 2019 06:30:10 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 DC5C01200C3 for ; Wed, 9 Oct 2019 06:30:09 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id j31so3406380qta.5 for ; Wed, 09 Oct 2019 06:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=IdBFH+e6OX56lG3aOFrgSTEe6QOUX4ug3Rxn8/smr6A=; b=pvxClfohBsBBNyDRLS6QZS8DX87/p3nALmkFu3ccd5QLMhei14YL7GS/2xV8EDXic5 GsKX8ooAjP2p2LXcULkffmNTUF7psUzZuN9DklRug/a9yf7qHYjQyBYPYWTmlceSBf79 /tBad1ZuY9ryu4T/oSHOHdjZC3FqHvuLqK/9nHzsOMdVdYHeu+hLojjGMpGkgR0JfZKL xBSY0HxaKa7Unp0RF+U62hwZtn9aTGzQlvh21nAYomAJLq/tEtqJJAjt3ybyke424WCP PDx3u/xsTtaCmLO2MVXz/HToQmM1v2wX4+u0uB8R5bMe3ZvmTXzOm5Mw9YU472gxbQ6k FxTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=IdBFH+e6OX56lG3aOFrgSTEe6QOUX4ug3Rxn8/smr6A=; b=Ps+JyR8w+ue1tu0W4DZT8xKjTOoXasmO4Bew5dtAxtdXYpWDmWToPWw0rDPCqzhZDU Jihc00vWSh/HqtpE5v/m22XdVRJCnp8xqRb+h5TD+jUsOsx5jk/+u7R8JLqrMPUpxX/y 6b9+IBpWmLTgQ9Ag+N38xlMCvujU80XNkWuYIJYwwG+0ErvJ+VZAtqiPAPxXTnBfQJT6 X9/BcuB5H5eUiZmb/zl7CIx3zPYnRJW4wOImTUXByUm00MHuMoE4GO7F/4Hbq4VWIuDq 9nXImlNXPMApK7yEWSU94YjWmrcM3dgSwZkigEnId2jDd+fiFt6t2Zp0H6R30rGDty8j Xh/A== X-Gm-Message-State: APjAAAW4YJqIQq+sh3ggxe+Grjr+Ody0WxzIm6/1TiXRrb4C4o4hpU1A zk4s3d4bjEJOaRlKTEjHp9bMaI+DNjQ= X-Google-Smtp-Source: APXvYqyeZItQP6hJ9ImASSxPDdyfLDnZ7KN+ppTo7yhLGH3VP+ldokXkx6JtG9z2zg/RqLbhsdAc2Q== X-Received: by 2002:ac8:3917:: with SMTP id s23mr3624440qtb.23.1570627808770; Wed, 09 Oct 2019 06:30:08 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id w73sm916598qkb.111.2019.10.09.06.30.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 06:30:07 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E1A22ED2-BFAF-4D4E-A5F1-3FF2900D7FEF Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 9 Oct 2019 09:30:06 -0400 Message-Id: <6133EC92-F957-4D64-9CFE-AFC5D210B4EB@fugue.com> References: <23964.55791.591141.356687@gro.dd.org> Cc: ADD Mailing list In-Reply-To: <23964.55791.591141.356687@gro.dd.org> To: Dave Lawrence X-Mailer: iPhone Mail (17A850) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 13:30:13 -0000 --Apple-Mail-E1A22ED2-BFAF-4D4E-A5F1-3FF2900D7FEF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable IoW dns filtering is not sufficiently effective at stopping botnet controlle= r lookups compared to other alternatives? What other alternatives? This is= n=E2=80=99t an interesting clarification unless there is something else botn= ets could be using but aren=E2=80=99t because dns is better. AFAIK botnets h= ave no useful alternative.=20 > On Oct 9, 2019, at 03:37, Dave Lawrence wrote: >=20 > =EF=BB=BFTed Lemon writes: >> Why do you think botnets bother to use DNS to find C&C controllers, >> even though DNS has been being used as a way to mitigate malware for >> years? If they could do it some other way, wouldn=E2=80=99t they have d= one so?=20 >=20 > Certainly one other way of interpreting this state of affairs is that > they still do because the mitigations haven't been effective enough. >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail-E1A22ED2-BFAF-4D4E-A5F1-3FF2900D7FEF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
IoW dns filtering is not s= ufficiently effective at stopping botnet controller lookups compared to othe= r alternatives?  What other alternatives?  This isn=E2=80=99= t an interesting clarification unless there is something else botnets could b= e using but aren=E2=80=99t because dns is better.  AFAIK botnets have n= o useful alternative. 

On Oct 9, 2019, at 03:37, Dave Lawrence <tale@dd.org> wrote:
=EF=BB=BFTed Lemon writes:
Why do you th= ink botnets bother to use DNS to find C&C controllers,
even though DNS has been being used as= a way to mitigate malware for
years?   If they could do it some other way, wouldn=E2=80= =99t they have done so?

Certa= inly one other way of interpreting this state of affairs is that
<= span>they still do because the mitigations haven't been effective enough.

--
Add mailing listAdd@ietf.org
https://www.ietf.org/mailman/listinfo/a= dd
= --Apple-Mail-E1A22ED2-BFAF-4D4E-A5F1-3FF2900D7FEF-- From nobody Wed Oct 9 06:31: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 6C75D1200C3 for ; Wed, 9 Oct 2019 06:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 LoVGDyvS9pz6 for ; Wed, 9 Oct 2019 06:31:19 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 0DB7E1200F7 for ; Wed, 9 Oct 2019 06:31:19 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id c6so4850581ioo.13 for ; Wed, 09 Oct 2019 06:31:19 -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:content-transfer-encoding; bh=lJNetTfp+WPjeFK8WwbtzXp1rBQH+ulYjdpPDdJE3ms=; b=gzuY8NBqLSf9OdFwEaM9D2Q08ALor2BtIJwd+SEWeFBQmKGx7r4FRR9P1pv1CA03Yv zCVO3ba6BW/7i43+lSz+OlwybygmVWYS2XQuN6Gku3CKm+eu7Aol7mWYMNbMnPqSmL6+ oqpwNduwiIb3OdCdRlBFrRngRyJSAk7456jescm/E5cUN7SWRMfXhl+6/h4p6BJuX2yk kEynAPHzdNncCVQ4iOgv/+/ChT3PRBz+GJpMvZoBzITXe92OjoH8yl9TkWyfGpWVbiFV 8SmDXaZz6RPEowDDdhSQfKoZcyK72SUywfFfgDGaXBbxv8i+ceglSZf9p5uPAfY8QJW2 wVfg== X-Gm-Message-State: APjAAAWpUsiXiF6kLsDj2Qilk709GZnwgnh7Ewyfvnjn2mXGuG1r5ETB ID7tVf7hUVM9CJ2STcv7N/xpthgb5pVZx1gZceo= X-Google-Smtp-Source: APXvYqxXCbdJQWQVEzHg++V7gjcCa6r1lF7VTDfu0NB6/xRPEfdAXtSNAll/hFuqy069POn3b5ppp7XRQ0Rq01jZoVA= X-Received: by 2002:a02:2244:: with SMTP id o65mr2999415jao.118.1570627878017; Wed, 09 Oct 2019 06:31:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Wed, 9 Oct 2019 15:31:06 +0200 Message-ID: To: Rob Sayre Cc: add@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:31:21 -0000 > Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 indivi= duals, rather than a mailing list? That's a fair question. The answers are: - The IESG write the charter proposal as something to float to the communit= y. - We took longer than we would have liked to get it done, and we wanted to be sure we had it ready for discussion as soon as possible, and to be sure we had a reasonable placeholder for BoF approval (today). That was sloppy, and I'm sorry for that, but we also did not have time to get it socialized and to have people signed up as proponents and possible chairs yet. So if it helps, consider "the IESG" as the charter proposal writers and "5 or 6 ADs" as the BoF proponents. Barry On Wed, Oct 9, 2019 at 10:55 AM Rob Sayre wrote: > > On Wed, Oct 9, 2019 at 2:39 PM Barry Leiba wrot= e: > >> >> I realize that the charter proposal isn't going to please everyone >> (and perhaps will please no one), but it's something that, at a first >> level of review, the IESG accepts and will likely want to move forward >> with. > > > Hi, > > Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 indivi= duals, rather than a mailing list? > > The proposed charter looks extremely misguided to me. But a proposal that= no one will put their name on doesn=E2=80=99t even deserve an argument. > > thanks, > Rob > > From nobody Wed Oct 9 06:36:15 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 2C781120108 for ; Wed, 9 Oct 2019 06:36: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 (1024-bit key) header.d=bt.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 kE8GdaAMR02U for ; Wed, 9 Oct 2019 06:36:11 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD31120106 for ; Wed, 9 Oct 2019 06:36:10 -0700 (PDT) Received: from tpw09926dag06g.domain1.systemhost.net (10.9.202.29) by BWP09926082.bt.com (10.36.82.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 9 Oct 2019 14:36:03 +0100 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by tpw09926dag06g.domain1.systemhost.net (10.9.202.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 9 Oct 2019 14:36:07 +0100 Received: from RDW083A011ED67.bt.com (10.187.98.37) by tpw09926dag18e.domain1.systemhost.net (10.9.212.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 9 Oct 2019 14:36:07 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.50) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 9 Oct 2019 14:42:31 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mk7gq/DRdPkJ15isa3h977DPsNlTDmnf7orJB4xrXuMqxzKTW2aCp+PZuXTIRzkWms1ZpWd2PBBUrZSr9tu+PP62vxwNg2cSR5N3MKWRl23YOfgFSS/wUitSp91JTshkaqU9zt8E35kCr88Ae8S37AkX/tHDHAQAtmgLPbQdBior6Or/mL2v+P3DFzRkUgDgCkqUqLwKgxA5v5d5YditD7X3HaFS13/m4bHTSRXjuVsJmVCSirlYNqZN8bpYYWirYY5fJJTGuyECQXgP9IGE3Budzoc3Z83ciTo5EqbGUIq0tEMMiUCd7aLkOxcq7IsSvJt7TTKVC0jTrTEUTIDznQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oD8CF+Pg7rGgCwMoku05amQCoP41sEHKjUYb7KP/5Y0=; b=RINJGXT1eNDWnuxCOHexYOkROkN7ZdFD2NNiteMkEdvDNPtauqWXsGwLmRpTo4LJqSkh9LgcOEPnona5AWiQbbL8DkIKl9B5IDZn6uLycgtRupJ386UAtD01CQ0R2z+W4LGzWDQAHiFGwq8wKyqkG2LyJvj+BgetubEKYI9MBvjJPUZQFbtwbKcWqcedtVozSXaI/OWWmQvhd3WmBokvkQyLrsJWfOWlAIvfVel7dokaobqE2xQNidxxZGffeV56+VKpJfljmULdIVobcIX0/sN0YsKSxWJUVFPDZBg12rgMOTuDr85IsN16KWmwa1wZAgkhJgZjLNazVUF0SUzIHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oD8CF+Pg7rGgCwMoku05amQCoP41sEHKjUYb7KP/5Y0=; b=LQwLJUvQAw5Qf4MQftcVsRxvd3TD/uTiZoRykHC2+zMiS+Lw6EQXHnmB20u78b27wSjcKsbuF/yfMBjHY8/qkj4+36R4VfWlCY3dKqPOy2eBqMZPhVeDm1BiQkmKsIZJiSrNn2QF9Aq+JyJXbBgc/eEYPQvGBvN0/oiY/UV5jlQ= Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM (20.176.158.15) by LO2P123MB2221.GBRP123.PROD.OUTLOOK.COM (20.176.156.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Wed, 9 Oct 2019 13:36:06 +0000 Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::dd6a:f080:9df6:1f56]) by LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::dd6a:f080:9df6:1f56%7]) with mapi id 15.20.2305.023; Wed, 9 Oct 2019 13:36:05 +0000 From: To: Thread-Topic: [Add] Proposed charter and BoF request for IETF 106 Thread-Index: AQHVfnSoqWCRx2OPVUOUSXPqDCOCg6dSNM6AgAAV++A= Date: Wed, 9 Oct 2019 13:36:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=chris.box@bt.com; x-originating-ip: [217.39.12.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d759edc3-bcce-4b46-e6f7-08d74cbda2c8 x-ms-traffictypediagnostic: LO2P123MB2221: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(51914003)(189003)(199004)(55016002)(229853002)(6246003)(316002)(81156014)(52536014)(81166006)(66066001)(71200400001)(99286004)(76116006)(14454004)(64756008)(66556008)(33656002)(66476007)(66446008)(66946007)(256004)(6116002)(71190400001)(6916009)(3846002)(8676002)(478600001)(2906002)(26005)(9686003)(86362001)(5660300002)(186003)(305945005)(446003)(476003)(25786009)(11346002)(486006)(7736002)(6506007)(102836004)(7696005)(6436002)(8936002)(74316002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB2221; H:LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qqOYtwcK7coqZszAxMIX+xhgpdcMRwXo/Ya/NJgGn3LCVAxKSW9XOXJvwdH/5y1KhnwSYrn8NvKZxZGEh0PVrxTf66ZXPOpuSpqrhhPFqIEI7kkR6n64/BkNKGneC1abLQf8O8yn2dpgaWSLbenQyMDR+EICpFg65P4cQBodXoM+1inyhBwXV/oZ7scfGrSZFzUesj8THiCPla9cVbAS5Nqt+UiQ0Fy6Af6UonkkTbJkwCFTlE2YVD9PaWL+CfgqmdwbtlGn6ztaF3XQiBElAhDwLkyf/8tqYbvcnSYTRjBbcRQUAMrB3okK+ERIUNo7GnB2uw6ry3qMr9FjpKhwV1WVGCfLZwiQGwZdrCctJ6qvOpdO8Pk3HdvdFDQav78Qe0xBhtEQW5daKGhkH97lILtwRP0jn4cN2nYjXe8BrQo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d759edc3-bcce-4b46-e6f7-08d74cbda2c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 13:36:05.9140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /bFix9ugTl0hkhzw0OqgDesKLJO5roAHhvjsX//FxbbxnMhlWD4Y56Om12bUKpnWEpmnBE8OyprylIItzKrN+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2221 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:36:13 -0000 QmFycnksIEkgc2Vjb25kIHRoZSB0aGFua3MgZm9yIHRoZSBjaGFydGVyLCB3aGljaCBpbiBnZW5l cmFsIGxvb2tzIHRvIG1lIHRoYXQgaXQgY291bGQgYmUgYSBnb29kIHdheSBmb3J3YXJkLg0KDQpJ J2xsIHBpY2sgdXAgb24gYSBjb3VwbGUgb2YgRWtyJ3MgcG9pbnRzOg0KDQo+IEkgdGhpbmsgd2Ug c2hvdWxkIHN0YXkgYXdheSBmcm9tDQo+IGFueXRoaW5nIHRoYXQgaXMgYWJvdXQgc3BlY2lmeWlu ZyBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIGJlY2F1c2UgYXMNCj4gZmFyIGFzIEkgY2FuIHRlbGwg YWxsIGJ1dCB0aGUgbW9zdCB0cml2aWFsIG9uZXMgKGhlcmUgaXMgaG93IHRvIHNhZmVseQ0KPiBy dW4gYSBUTFMgc2VydmVyIG9yIHNvbWV0aGluZykgYXJlIGNvbnRlc3RlZC4gRm9yIGluc3RhbmNl LCBldmVuDQo+IHJldGVudGlvbiBwZXJpb2QgaGFzIHZlcnkgc3Ryb25nIHZpZXdzIG9uIGJvdGgg c2lkZXMuDQoNCkluIG15IHZpZXcgQkNQcyBhcmUgY2xlYXJseSBuZWVkZWQsIGFzIGEgbWVhbnMg b2YgcmVzb2x2aW5nIHRoZSBjb250ZXN0ZWQgYXJlYXMuIElmIEkgdGhvdWdodCByb3VnaCBjb25j ZW5zdXMgd2FzIGltcG9zc2libGUgSSB3b3VsZCBhZ3JlZSB3aXRoIEVyaWMsIGJ1dCBJJ20gbW9y ZSBvcHRpbWlzdGljLg0KDQo+IFRoaXMgbGlzdCBvZiBwcmFjdGljZXMgd291bGQgYmUgbXVjaCBt b3JlIGFjY3VyYXRlIGlmIGl0IGluY2x1ZGVkIHRoZQ0KPiByZXNvbHZlci1sZXZlbCBETlMgcHJh Y3RpY2VzIHRoYXQgd2UgYXJlIHRyeWluZyB0byBtaXRpZ2F0ZSB1c2luZyBEb0gsDQo+IGluY2x1 ZGluZyBOWERPTUFJTiBzeW50aGVzaXMgYW5kIGNvbGxlY3Rpb24gb2YgdXNlciBicm93c2luZyBo aXN0b3J5DQo+IGRhdGEuDQo+IEp1c3QgaGF2aW5nIG5ldHdvcmsgb3BlcmF0b3JzIHRyYW5zaXRp b24gdG8gc2VjdXJlIHRyYW5zcG9ydHMgd2hpbGUNCj4gY29udGludWluZyB0aGVpciBjdXJyZW50 IHByYWN0aWNlcyBkb2VzIG5vdCBhZGRyZXNzIHRoZSBpc3N1ZS4NCg0KUGxlYXNlIHBvaW50IG1l IHRvIGFuIG9wZXJhdG9yIHRoYXQgaXMgYXJndWluZyBmb3IgdGhlIGNvbnRpbnVpbmcgb2YgTlhE T01BSU4gbW9uZXRpc2F0aW9uLiBCVCBpcyBub3QsIG5vciBpcyBDb21jYXN0LiBJIGRvbid0IHNl ZSB3aHkgd2UgY2FuJ3QgaGF2ZSBBQkNEIHdvcmsgb24gYSBkZWNsYXJhdGlvbiB0aGF0IHRoZXNl IHByYWN0aXNlcyBhcmUgbm90IHBlcm1pc3NpYmxlIGV4Y2VwdCBpbiBkZWZpbmVkIGNpcmN1bXN0 YW5jZXMgKGUuZy4gdXNlcidzIGV4cHJlc3Mgd2lzaCwgcGVyaGFwcyBvdGhlcnMpLiBUaGUgc2ln bmFsbGluZyBvZiBwb2xpY2llcyB0aGF0IHlvdSByZWZlciB0byBjb3VsZCBiZSBwYXJ0IG9mIHRo YXQgc3RhdGVtZW50Lg0KDQo+IFRoaXMgc2VlbXMgbGlrZSBpdCBsZWF2ZXMgYWxsIG9mIHRoZSBj b250ZXN0ZWQgaXNzdWVzIGZpcm1seQ0KPiBpbiBzY29wZS4gSSBjYW4ndCBpbWFnaW5lIGhvdyB3 ZSdyZSBnb2luZyB0byBnZXQgY29uc2Vuc3VzIG9uDQo+IGJlc3QgY3VycmVudCBwcmFjdGljZXMs IHdoZW4gd2UgY2FuJ3QgZXZlbiBhZ3JlZSBvbiB0aGUgdGVybXMNCj4gZm9yIHJlc29sdmVyIHNl bGVjdGlvbi4NCg0KWWVzIGl0J3MgaGFyZCwgYW5kIHNvbWUgY29tcHJvbWlzZSB3aWxsIGJlIHJl cXVpcmVkLCBidXQgaXQncyB3b3J0aCBhdHRlbXB0aW5nIHRoaXMgaW4gQUJDRC4NCg0KQ2hyaXMN Cg== From nobody Wed Oct 9 06:36: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 9740A120106 for ; Wed, 9 Oct 2019 06:36:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 7L-NHbw920BL for ; Wed, 9 Oct 2019 06:36:57 -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 28CAD1200F7 for ; Wed, 9 Oct 2019 06:36:57 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id c25so4906562iot.12 for ; Wed, 09 Oct 2019 06:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yvCeRkFvtqZShmYvlwIr7xD/qRu32x+y3tuKnzDVNZ0=; b=bt9237iRwLDOjXa/4pQ6X6IdaP+3WXtD7AZHdnLshxMTXkV6BPZxY89z1zKRjcsuy3 SMsvJU34KYnpes2Fq1v9A2TllzWS4jlaCYiLL6ZqyQObez6qy3REUEhaMXSr8Nlt7CmH dhpldggI9pq7tkgNCkIdtqAYeqomlmyplSl6A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yvCeRkFvtqZShmYvlwIr7xD/qRu32x+y3tuKnzDVNZ0=; b=Ugs5VCvPWmMp95k/NU1nW0IuzDhL7ffJ8ehjEnGjH9+bYIN5YS/VJU9Fqt4UcznK29 AXyuAOb+kd75Z3HQ/Nq6MlHRJCic82YSHYs0pw19FDD6chncicye1pgLU+HXT30iqibi UcIALG9lI1aLO6rGYf5Uftc5tEFPpsUgMIscLPn8YExZBTrzOkCskC157g/HMTwCyXiZ Dp1wdzQcN4GXNyyqZ8UxE/uGWUe4Q5jXj9G19bOgv1ZEylC/5+VcPn/snHp6cjZN9kjR fwaRIUMpMhn7+1ZVUR6O3uGSCIOGeyGLoJZOgk6wT0YnwjFFHjabaa3bOTglD4r6mq94 tguw== X-Gm-Message-State: APjAAAUMxN2ZN41S+nkynopsFFQ8EjX4SwjlWSzaB3D7qnMDsDJc34Ve 6J3pU3a51ZgjeDbksj4qaPkX7A== X-Google-Smtp-Source: APXvYqzqblaOZhaqUnQXti9nO8Y6w066ii878Snce5su7Mg5vk/P9MOVGnIlyM9lIB1R4N6jcqhvgQ== X-Received: by 2002:a5d:870c:: with SMTP id u12mr931053iom.95.1570628216436; Wed, 09 Oct 2019 06:36:56 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:9040:dbfa:a425:dac9? ([2607:f2c0:e786:128f:9040:dbfa:a425:dac9]) by smtp.gmail.com with ESMTPSA id h4sm908489iom.17.2019.10.09.06.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 06:36:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Joe Abley In-Reply-To: <23964.55791.591141.356687@gro.dd.org> Date: Wed, 9 Oct 2019 09:36:54 -0400 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <0B781E27-8B8A-4718-8269-73E8A9DCE46A@hopcount.ca> References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> <23964.55791.591141.356687@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 13:36:59 -0000 On 8 Oct 2019, at 14:48, Dave Lawrence wrote: > Ted Lemon writes: >> Why do you think botnets bother to use DNS to find C&C controllers, >> even though DNS has been being used as a way to mitigate malware for >> years? If they could do it some other way, wouldn=E2=80=99t they = have done so?=20 >=20 > Certainly one other way of interpreting this state of affairs is that > they still do because the mitigations haven't been effective enough. Another way of interpreting that statement is that perhaps the only = botnets we know about are the ones that use DNS to find C&C controllers; = it could well be that there are significant numbers of botnets that do = it some other way that we can't see. Joe= From nobody Wed Oct 9 06:41: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 2A391120106 for ; Wed, 9 Oct 2019 06:41:10 -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_HELO_NONE=0.001, 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 R37uJnFQLqBF for ; Wed, 9 Oct 2019 06:41:08 -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 C4BBD1200F7 for ; Wed, 9 Oct 2019 06:41:08 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q1so5094523ion.1 for ; Wed, 09 Oct 2019 06:41: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=WYQOA7meuwESQgdbm/KTrRLmLkaRMJLn82RGiY9qVR0=; b=FLq5BOIZOHFI7//lc//ZJk5EuP9RHFeS4re5BnoHR75G8YvPOatLM3zflBsSza+riW 0C0Ui6z7qYPB5UnY+kMt8oSZhKJZ+ldIzsPgHdVKsUdqdU3JRAC1RBtZclhelnNhqXUA R127eJU2d3P7ei9wl/N50kffU5jDAUb5SqKexzDWidaojo4oAQ6BgCTXQVpiUrPvHpEh 4fk1lAdePG8PGxmzn8eN7qlQ5D0BxjH+5bp4ABex/1W1M3TlNGA8y9mN7lnY/bup/WSE BdkWxriAskBDgaBXdGkUVVbMb51avxyBOpRRoXgTmmlf1b7Tf8/BdBWLx2VDKBUtgeWe IYZQ== 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=WYQOA7meuwESQgdbm/KTrRLmLkaRMJLn82RGiY9qVR0=; b=rngCxCDKJFr3AvMhGyd55hxK4LzeA7Ann9/F+vDfO4CAMkZIxk94D5n6hiDFVazPcF igZ8AUlr1Ljzuq42jm92l8BCaIE0WzjaX/zllFKh87X4CCbP2pbZzWGuzh5nGaZn0iLa TVbXasfFwhPQwETlu8lcWqyFi6Rd1fcH72+xE6VruJjTl2y6ZbOMfRGY/N20ShwS+FBJ 968ULYAFMSzc4dEtAQ/MwKV3kBj6Dz7GLJWBVNX5pYxH/poRLx8DyWPyarptL5RlKyc0 MiwClcvedPZ/kDv/XUP+CvHGVPTrY47Nzgi4hzbpz0s/4F0fTHBHrar+DF/kqPJLd7zk McAQ== X-Gm-Message-State: APjAAAVCp5Y8e/mKQz1vq9aUdBUC3I4m5zAgmEdsCWK/LzjBQHQgaAAb MG7VxSv5vb/4iC7HtS+wHLNhtJtBclMHDUMFQ+4= X-Google-Smtp-Source: APXvYqzgxeGvqtLLIzWdFrFeH4m30IFmv//ZZdM/40xQmEzcSHBRWBwlh5IqBz92QyrYBmP4Ibs/ak+0bKKH7EHV9jU= X-Received: by 2002:a6b:b807:: with SMTP id i7mr3381428iof.254.1570628467936; Wed, 09 Oct 2019 06:41:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 20:40:56 +0700 Message-ID: To: Barry Leiba Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e7d3d905947a6ff0" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:41:10 -0000 --000000000000e7d3d905947a6ff0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 8:31 PM Barry Leiba wrote: > > Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 indi= viduals, > rather than a mailing list? > > That's a fair question. The answers are: > Thank you for the response. > So if it helps, consider "the IESG" as the charter proposal writers > and "5 or 6 ADs" as the BoF proponents. > It does not help. Could those "5 or 6 ADs" put their names on the proposal? thanks, Rob --000000000000e7d3d905947a6ff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 8:31 PM Barry = Leiba <barryleiba@computer.or= g> wrote:
> Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 in= dividuals, rather than a mailing list?

That's a fair question.=C2=A0 The answers are:
Thank you for the response.


So if it helps, consider "the IESG" as the charter proposal write= rs
and "5 or 6 ADs" as the BoF proponents.

=
It does not help. Could those "5 or 6 ADs" put their n= ames on the proposal?

thanks,
Rob=C2=A0<= /div>
--000000000000e7d3d905947a6ff0-- From nobody Wed Oct 9 06:48: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 27A88120115 for ; Wed, 9 Oct 2019 06:48:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 eZgIAf6TbIpl for ; Wed, 9 Oct 2019 06:48:47 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 B615312011F for ; Wed, 9 Oct 2019 06:48:47 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id z19so5173254ior.0 for ; Wed, 09 Oct 2019 06:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=baTsDkuVf31r9Wpfh4i2U+iOycMmSyHA6SZCeAe2a1Y=; b=D6wuVeP3R73uNzQzaeITDkvqa1gN+WpjHYpOjrPRqfVAwtVYzcowIcxXUY4ee2Ho0u A/M2kYmkLbUnXFoO9a1tyr/Eyq0Q9rI39VJ9bA7FSU5/vKjhuqQ+sUc/MakrBH5MupH7 GGj5qwYC6me853xuqaIs5zYHqei9Ba9v7IBeI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=baTsDkuVf31r9Wpfh4i2U+iOycMmSyHA6SZCeAe2a1Y=; b=i3wBYf4pSwNa7dbRpeG1dSOuODWHDQFIdyZa/8wQiIuJofJSZVjydq5QQZG13aABiy upxf/E5nSX1GTuzrVHsloUI1YWyIO8XBF7PPORK3H3x6aH0lJulcD02MLIEUVS/VdUq/ iiTnz/3KKfvYyaTnkpkVEv/SWldgyJIxt0fiC9ai4D+6tCH0Bt6AgIRsjFKT+zEzw+Cy t6C1PwZ+EKiQGoJ+jORMyZMft7r16iX5vWTj+lUJ2ivieMY1Tz+nHPfpRaHGL4kDvRoH +7XC1w6yUO9v4PbRfNe6p8SaJX1+0aWeaAX7VY0VcL3fL1knKijYX4QmyPV/nqxQOfam vsxw== X-Gm-Message-State: APjAAAWQ0lBpm9sEqokw10CN5FSkqzDpGNSlRNUsnKNyCpGV15rm/8yt Yn8K0KwF/py9q7iZXaRPPbHcF7LWV/egXZ6g X-Google-Smtp-Source: APXvYqx4Bx14HAtQlKNIjIKjuzVekd/yKOUe/UrG9VEwnu/BpvhsYMelsI2+12/a9Rd0aX0KjBN7qQ== X-Received: by 2002:a6b:6f0b:: with SMTP id k11mr3260590ioc.243.1570628926821; Wed, 09 Oct 2019 06:48:46 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:9040:dbfa:a425:dac9? ([2607:f2c0:e786:128f:9040:dbfa:a425:dac9]) by smtp.gmail.com with ESMTPSA id 197sm1006325ioc.78.2019.10.09.06.48.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 06:48:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Joe Abley In-Reply-To: Date: Wed, 9 Oct 2019 09:48:44 -0400 Cc: Barry Leiba , ADD Mailing list Content-Transfer-Encoding: 7bit Message-Id: References: To: Rob Sayre X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:48:49 -0000 Hi Rob, On 9 Oct 2019, at 09:40, Rob Sayre wrote: >> So if it helps, consider "the IESG" as the charter proposal writers >> and "5 or 6 ADs" as the BoF proponents. > > It does not help. Could those "5 or 6 ADs" put their names on the proposal? Can you explain why this is important? I don't mean to imply it's not; I'm just trying to understand your question. Joe From nobody Wed Oct 9 06: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 6DE9912012D for ; Wed, 9 Oct 2019 06:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 hubzqEWIkLU3 for ; Wed, 9 Oct 2019 06:50:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6710212021D for ; Wed, 9 Oct 2019 06:50:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7F565660169; Wed, 9 Oct 2019 16:50:43 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgiDZXKSJtrj; Wed, 9 Oct 2019 16:50:42 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 4E87C6600AF; Wed, 9 Oct 2019 16:50:42 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 9 Oct 2019 15:50:41 +0200 Cc: Barry Leiba , ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.net> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:50:47 -0000 (I should acknowledge that the privacy and deployment model related text = in Barry=E2=80=99s text was proposal from me. But the whole charter text = should be considered as a proposal and subject for discussion and = modification.) Back to Ekr=E2=80=99s point: I do think the technical discovery etc = parts are very important and should be worked on. But I also think that = we have to say something about privacy, pervasive monitoring and = centralisation issues. =46rom my perspective if we work on this topic at = all, we=E2=80=99d be not doing our duty if we didn=E2=80=99t consider = those aspects. Jari From nobody Wed Oct 9 06:52: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 16CB612011D for ; Wed, 9 Oct 2019 06:52:03 -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_HELO_NONE=0.001, 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 eKpshMMKrE3l for ; Wed, 9 Oct 2019 06:52:01 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 628DA120115 for ; Wed, 9 Oct 2019 06:52:01 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id v2so5057115iob.10 for ; Wed, 09 Oct 2019 06:52:01 -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=ptLLPdiurEBGyPP1Wcxu/aGHUXKOPnCCpY738uiJgXY=; b=AF1tZfILwwoMX0SQB9i55+ux1QX/G3lrX9XngqdSxXBxd2c6XkCPtH7Ld66ADluXJZ JBR2CYVQtkKuM3jyruchSPiUN4tbb2oFYUtHVPoIUfM7h1QCeXyGtaPOqQOc7vCdPwNB eHxiAYou/CWbereu56hKd0cQ2pzvPZR4Oz2WHZmxpKUP/xdPQFSpKvtjS+rE+z41VoZy YZKmJgumxwy3986xJ39yUBO8SWu1OF8VKKIY6pfMtAl1eHf/Ci/AkPIcD+UKjVjeQItW 9ENTU8HPBjLRFV+K4V/jQ811gjLxjSV1b1GP0xYlNTijm5EFIIJR1llOfo7AMBNbVPdY 2UnQ== 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=ptLLPdiurEBGyPP1Wcxu/aGHUXKOPnCCpY738uiJgXY=; b=h464yUro4Zueo6W4XdSYtaLoHyC8PueLtGVtyxhERST27MIzLix/SVAH0Wuhuu9dXy ML9bLdxg/MDoMvvT7aTJ0oh5OO0yZaGeeqFpC2yhhh5z51LkZgCECIu+2xKM7ouHFrXs jS5XzQOjxweRU4QCXqeLmtEPq9o1sLtJKmzl48Ak8uAHIvdjiKxZH38rKXQsQvMFy2AH xUamg2pR7Aivagx1J99K1HsmxNV6Xy/x5DO0lfwAFsZDfvsqHFQzTWs7US1kxCCvH2bv Ij474moTtATQSCVjf++p/Fiy1N8WFPqAWqbKOzvGAm8xAkHXyzb6et4llbprOP3Br1PN 8AKA== X-Gm-Message-State: APjAAAVQx86hGGLDSAOp4M2fpoyXKM4nZIWbn/BKJ/dI6fgPt+hvFfVq pG8JOYjjCiYwTRNcXoIqFD2mydqQ8nGrsV/8PoI= X-Google-Smtp-Source: APXvYqxPg3jZym8h6KDIr4shMy6D+OjMuH0tWMs3EmDugzKHCLLnAJn6Yv7GcZ50B0xrwuZj6xhUgK0cYQHGyW9SMf4= X-Received: by 2002:a5d:8f83:: with SMTP id l3mr3422481iol.73.1570629120692; Wed, 09 Oct 2019 06:52:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 20:51:43 +0700 Message-ID: To: Joe Abley Cc: Barry Leiba , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000d01a3b05947a96f3" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:52:03 -0000 --000000000000d01a3b05947a96f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 8:48 PM Joe Abley wrote: > Hi Rob, > > On 9 Oct 2019, at 09:40, Rob Sayre wrote: > > >> So if it helps, consider "the IESG" as the charter proposal writers > >> and "5 or 6 ADs" as the BoF proponents. > > > > It does not help. Could those "5 or 6 ADs" put their names on the > proposal? > > Can you explain why this is important? > > I don't mean to imply it's not; I'm just trying to understand your > question. > You ask a totally fair question. I think the charter is misguided and wrote that "a proposal that no one will put their name on doesn=E2=80=99t even deserve an argument." So, I just asked (again) whether someone would put their name on it. thanks, Rob --000000000000d01a3b05947a96f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 8:48 PM Joe Ab= ley <jabley@hopcount.ca> wr= ote:
Hi Rob,

On 9 Oct 2019, at 09:40, Rob Sayre <sayrer@gmail.com> wrote:

>> So if it helps, consider "the IESG" as the charter propo= sal writers
>> and "5 or 6 ADs" as the BoF proponents.
>
> It does not help. Could those "5 or 6 ADs" put their names o= n the proposal?

Can you explain why this is important?

I don't mean to imply it's not; I'm just trying to understand y= our question.

You ask a totally fair qu= estion.

I think the charter is misguided and wrote= that "a proposal that no one will put their name on doesn=E2=80=99t e= ven deserve an argument."=C2=A0

So, I just as= ked=C2=A0(again) whether someone would put their name on it.

=
thanks,
Rob
--000000000000d01a3b05947a96f3-- From nobody Wed Oct 9 06:52: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 5981B12012D for ; Wed, 9 Oct 2019 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFsc_bigFCse for ; Wed, 9 Oct 2019 06:52:09 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DE6120154 for ; Wed, 9 Oct 2019 06:52:08 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 72so1731658lfh.6 for ; Wed, 09 Oct 2019 06:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cH9G22bkTzYAG53GFQV5UOOAS/TKU9J896GrALIN9G4=; b=p4iJar/uzKyeMM8CNJFEfIeDKHGYqDgtx5jjMq8XpaIoqjWBMqAWdHzl11C1hPuwL0 TxdncgeebCmkF0nWmvvEwo6syg1BUTYrCLnGfOiYokanoG4MShrFBiRouJf1NTGco2AW EewLXZhHR8Uq9a3OlMSChRekvwy1Utb3qTzT6BbYGV+LZVvySQ/d69ki9r8fjGr3fLjD 0laagz/c3+V2Vpc9rjH6OzWQijSd93Ry2+n8B5DaNsBMMauj0UthPx7ztasb9123Xw4r wr4joqHIak2LpsXVAu6ibR+cQTJmqIYDZT1X1mzZhfjCMEajrRon/x2DPWzJsPiXt+gl G2qg== 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=cH9G22bkTzYAG53GFQV5UOOAS/TKU9J896GrALIN9G4=; b=QbpOkvBqJjCg57czbKmt6ZlQdBIh0RlcmQeIGWunR3gJjs+E28+Ke2VivNRSNx/KfV lCV+501dMUAahi7OOu45qk866BX4mlZBdz5xvRI9LmFGep+gDNVVwv89K2XM/hxvCYR/ C/iE4CMwUbRXP40MfuWJfLDyeOn3h2DarCEZoP/jjzVG/SSzC4ZRrq4zIBwdHksQ59G2 eiPB6IkDeBvRxqhGQak/Ngl/yR5BWKjQW+UCYLmCWHEQY0qvYjns0rpquqQOC0B3X8qG ZnO01yzCVmdIf5amj3TlVuP6H6G1CchDJnL4d9fYmHMsgcrtwKKWrNG6h7YHzkmlEFLF 5VNw== X-Gm-Message-State: APjAAAXhwnzO3nU6G+JzfS8y8QM0paCunp6GiNZibgtRQT1tjujbuvva YXtsTmUmbNnRxTohi9dOe9C6WxaUjfMmjzCCOHZHqQ== X-Google-Smtp-Source: APXvYqx3R28XigmSdOU59fK5kSwwuZzGD5cPuimcI1ZV8cjhFeGDbaeTdW9ASmVGxA8HbbZUb3YmeEJOQCJGVo74+LI= X-Received: by 2002:a19:4a02:: with SMTP id x2mr2036280lfa.17.1570629127081; Wed, 09 Oct 2019 06:52:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 06:51:30 -0700 Message-ID: To: chris.box@bt.com Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000031a1c405947a97d3" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:52:11 -0000 --00000000000031a1c405947a97d3 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 6:36 AM wrote: > > This list of practices would be much more accurate if it included the > > resolver-level DNS practices that we are trying to mitigate using DoH, > > including NXDOMAIN synthesis and collection of user browsing history > > data. > > Just having network operators transition to secure transports while > > continuing their current practices does not address the issue. > > Please point me to an operator that is arguing for the continuing of > NXDOMAIN monetisation. Arguing or not, it continues to happen, at least on T-mobile. -Ekr --00000000000031a1c405947a97d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 6:36 AM <chris.box@bt.com> wrote:
=
> This list of practices would be much more accurate if it included the<= br> > resolver-level DNS practices that we are trying to mitigate using DoH,=
> including NXDOMAIN synthesis and collection of user browsing history > data.
> Just having network operators transition to secure transports while > continuing their current practices does not address the issue.

Please point me to an operator that is arguing for the continuing of NXDOMA= IN monetisation.

Arguing or not, it contin= ues to happen, at least on T-mobile.
=
-Ekr



--00000000000031a1c405947a97d3-- From nobody Wed Oct 9 06:52: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 CAAD312011F for ; Wed, 9 Oct 2019 06:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 IXltH_rvMY65 for ; Wed, 9 Oct 2019 06:52:23 -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 A50C112010C for ; Wed, 9 Oct 2019 06:52:23 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 5F2CE242153C; Wed, 9 Oct 2019 13:52:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Wed, 9 Oct 2019 14:52:20 +0100 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2D228282-0F33-43D5-8326-0271372230AF@rfc1035.com> References: To: chris.box@bt.com X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:52:26 -0000 > On 9 Oct 2019, at 14:36, wrote: >=20 >> This seems like it leaves all of the contested issues firmly >> in scope. I can't imagine how we're going to get consensus on >> best current practices, when we can't even agree on the terms >> for resolver selection. >=20 > Yes it's hard, and some compromise will be required, but it's worth = attempting this in ABCD. Indeed. And when consensus isn=E2=80=99t achievable, I think it would be = helpful to document the reasons why that=E2=80=99s the case. Even if = those hypothetical Informational RFCs were little more than a statement = of the bleedin=E2=80=99 obvious. For instance =E2=80=9CThe IETF has no = BCP on query data retention because that topic is an intractable tar pit = of conflicting/contradictory national regulations, legislation and local = policy. Here=E2=80=99s why: ... The WG decided not to go on a quest for = an unachievable compromise. Have a nice day.=E2=80=9D. IMO it will sometimes be helpful to document the things the WG doesn=E2=80= =99t agree on and why as it is to document the topics where there is a = (rough) consensus.= From nobody Wed Oct 9 06:56: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 98716120115 for ; Wed, 9 Oct 2019 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LNeLpSFb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BqBV7qc9 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 oF4wSa0gRyEJ for ; Wed, 9 Oct 2019 06:56:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24F812010C for ; Wed, 9 Oct 2019 06:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7927; q=dns/txt; s=iport; t=1570629365; x=1571838965; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kEZVobPvoIRVYaFt0QexB3wrzXR9srGOXivhFWJ5NWA=; b=LNeLpSFbmwzt8suiojHQ/UUzKd47FUOEQ8mEIopzfcAMSCtWStGQMyVQ NxWZwCPqRf7br7vM61P82E3J/+NTdDtq0nwRWc2/FjWW+ZDQVIF1exMa1 llZytx5osp53rLdKEr6RBAwi3NlhMlWExcz7kgPAD2MtbuGep7PhrXIH+ I=; IronPort-PHdr: =?us-ascii?q?9a23=3AEoRwVB0l7bAJ/nl2smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFPqKvXpYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAADj5Z1d/4MNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXuBHC9QA21WIAQLKoQjg0cDikSCXIl?= =?us-ascii?q?qiTKEYYJSA1QJAQEBDAEBLQIBAYRAAheCOCM4EwIDCQEBBAEBAQIBBQRthS0?= =?us-ascii?q?MhUsBAQEDARIRHQEBLAsBBAsCAQgRAwECAScDAgICHxEUCQgCBAENBSKDAAG?= =?us-ascii?q?BHU0DDg8BAqUbAoE4iGF1gTKCfQEBBYJJgkANC4IXCYE0jA4YgUA/gREnH4I?= =?us-ascii?q?eLj5rGQGBFYJKFoJYMoImj2+FN4kujjJBCoIikRGECBuZQI4tijCPBgIEAgQ?= =?us-ascii?q?FAg4BAQWBaSKBWHAVOyoBgkFQEBSBTxiDW4pTdIEpkzwBAQ?= X-IronPort-AV: E=Sophos;i="5.67,276,1566864000"; d="scan'208,217";a="347381640" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2019 13:56:03 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x99Du3RA023416 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2019 13:56:03 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 08:56:03 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 08:56:02 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 9 Oct 2019 08:56:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=meTXSMjEFhwmYTLoXVRpPBOcfWngHjDnoJwKGnOzrVJPuse/sxddaTlxbxUb1izB4BuJjjrJumLU4rjtDDiXjz1FiOc8Poux9PVTfteHDakMncle4jM4tndSIDuYmMVB0W4Iywh8WqsF06FURzv3p+98P2BHxenaPA8x5TSW3hMjKxP/mCuEwajrI4y4ceYMccPkwR+8ypgCDQlWFZqGCMDuzrzd5ySl/dn4IyK4S5k2qQx9cytskUNrQwa4YyRE0sx++sQeZo9pdA6utQDCKWTVLnZSMppndRSbLUpRU4ZthdIKbZm9ZbXCjuF3u+cdluiT1Wu1/5FWgVjLy88ZCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kEZVobPvoIRVYaFt0QexB3wrzXR9srGOXivhFWJ5NWA=; b=ZKkujM0mDkIFhwmx1LiuNYCklFkwgsfmxrQ1QcI30LS1LDPLw93BkxQh+XbxYYhk6KmoC0j4kmPHdU1USlRfT2aBDy1Ees1tzSVXea7pLVwYBYiZwTqAfHM1VBlHwpncJr5h5y7e2YFTSvls/uJ5Q0VjoGiPvaZuvVxt+e37TrvF1lZJ4Kvkmn9NCQwB9ZXLZr9QhROTkvfZ5xvRWDLnbViG+xfCofST1xY6iAf9wc/HlBIpxcu2x1zkVOPlI6xDatpmai8/IeG+OtayyQ2ZLVh+TK4ssEsgQglMUYfJMEt9q2MNx270fptsuVpcNy0MKIAxQ3o4ulegmMr2BoojnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kEZVobPvoIRVYaFt0QexB3wrzXR9srGOXivhFWJ5NWA=; b=BqBV7qc9VZ3Lrhv1b511IrHUxOarGRYMoqcUURyqOGHZKAwLOssJtWqW2QKGtT42bLAadOVnMahdK7jTy1Ww1RgCJQqo5TC+9Cym4Njc53ZuzmboDr0/iStT+CnDAVrWTKF4pXv8MwDuDjpmYdHB3xr/zd6Jnjqr/VTwEsuBeDU= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4189.namprd11.prod.outlook.com (20.179.150.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 9 Oct 2019 13:56:00 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2347.016; Wed, 9 Oct 2019 13:56:00 +0000 From: "Eric Vyncke (evyncke)" To: Rob Sayre , Barry Leiba CC: ADD Mailing list Thread-Topic: [Add] Proposed charter and BoF request for IETF 106 Thread-Index: AQHVfnSkBrNlnq14+kme+Fb6LfA+b6dSAX6AgABNMwCAAALAAIAAJbuA Date: Wed, 9 Oct 2019 13:56:00 +0000 Message-ID: <72E87905-63B1-45C3-8F1A-921E7B753E68@cisco.com> References: In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c0:1006::32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad108d0c-8007-46b1-0446-08d74cc06abc x-ms-traffictypediagnostic: MN2PR11MB4189: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(129404003)(199004)(189003)(561944003)(54896002)(33656002)(71200400001)(4326008)(6246003)(71190400001)(86362001)(236005)(6512007)(81166006)(81156014)(8676002)(8936002)(6436002)(6486002)(229853002)(58126008)(110136005)(316002)(486006)(2616005)(36756003)(476003)(6116002)(66946007)(66476007)(66556008)(66446008)(46003)(446003)(11346002)(91956017)(76116006)(5660300002)(4744005)(478600001)(64756008)(25786009)(14454004)(76176011)(256004)(6306002)(14444005)(99286004)(2906002)(7736002)(102836004)(186003)(6506007)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4189; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uWcjtYA40byL8LTgjrpEAdCeBvAk+ZBYc7/nfdCT5ZVuBEdprjYnpM5h3E1awlv4OOqV97CLkK256HUENsQ+D2pAWftMiP8Znsh0GFm9smGF0vDaO2KviUiwFbjBcqfL8pbqGGLLzO2WuKCoBAGLTqmKqPlDne6vfZ5usJJY1x6ilXG2VUqlHkjvxX7kWqH4lIVywPXU196RT9h+oqMK5JlME3A2q8m2+Y6YLrFiPuQISKbjfIL2JxdgTNw3tmUaoDBgCNXxwrirj+5bi7FWCmA1p2z+QXv62fh+5HvGkEH8dZcmzdeiVEon/0Su7+I0pSjRntHUSAuDj6H1X6VPtYoy9+aZj0TElYTObgPB7ufwyFlzEmo4OUMD7Sr7e/eIH9PVN052GULwJe1xJdYcL/2/fGinB9nbhxw6islMYOY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_72E8790563B145C38F1A921E7B753E68ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ad108d0c-8007-46b1-0446-08d74cc06abc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 13:56:00.2674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GZjaqLQqcBW4eAJ5SYQ6FSvTG2rTOJUlC0syR0VXEwafvDeMLzfWKh87BFkrDy/1ERCccwhZxoW7orLHHTIeoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4189 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:56:08 -0000 --_000_72E8790563B145C38F1A921E7B753E68ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iDQoNClRoZXJlIGlzIG5vIHNlY3JldCBvYnZpb3VzbHk6IEkgd2FzIG9uZSBvZiB0aG9zZSA1 LTYgYXJlYSBkaXJlY3RvcnMgKHdpdGggZHByaXZlIGluIG1pbmQpICAgOy0pDQoNCkhvcGUgdGhp cyBoZWxwcw0KDQotw6lyaWMNCg0KRnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIFJvYiBTYXlyZSA8c2F5cmVyQGdtYWlsLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwg OSBPY3RvYmVyIDIwMTkgYXQgMTU6NDENClRvOiBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21w dXRlci5vcmc+DQpDYzogQUREIE1haWxpbmcgbGlzdCA8YWRkQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtBZGRdIFByb3Bvc2VkIGNoYXJ0ZXIgYW5kIEJvRiByZXF1ZXN0IGZvciBJRVRGIDEwNg0K DQoNCg0KT24gV2VkLCBPY3QgOSwgMjAxOSBhdCA4OjMxIFBNIEJhcnJ5IExlaWJhIDxiYXJyeWxl aWJhQGNvbXB1dGVyLm9yZzxtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+PiB3cm90ZToN Cj4gV2hvIHdyb3RlIHRoZSBjaGFydGVyPyBTaG91bGRu4oCZdCB0aGUgQm9GIHByb3BvbmVudHMg YmUgMS0zIGluZGl2aWR1YWxzLCByYXRoZXIgdGhhbiBhIG1haWxpbmcgbGlzdD8NCg0KVGhhdCdz IGEgZmFpciBxdWVzdGlvbi4gIFRoZSBhbnN3ZXJzIGFyZToNCg0KVGhhbmsgeW91IGZvciB0aGUg cmVzcG9uc2UuDQoNCg0KU28gaWYgaXQgaGVscHMsIGNvbnNpZGVyICJ0aGUgSUVTRyIgYXMgdGhl IGNoYXJ0ZXIgcHJvcG9zYWwgd3JpdGVycw0KYW5kICI1IG9yIDYgQURzIiBhcyB0aGUgQm9GIHBy b3BvbmVudHMuDQoNCkl0IGRvZXMgbm90IGhlbHAuIENvdWxkIHRob3NlICI1IG9yIDYgQURzIiBw dXQgdGhlaXIgbmFtZXMgb24gdGhlIHByb3Bvc2FsPw0KDQp0aGFua3MsDQpSb2INCg== --_000_72E8790563B145C38F1A921E7B753E68ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0E345372A87C8445869DC7059030DA66@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Sb2I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgbm8g c2VjcmV0IG9idmlvdXNseTogSSB3YXMgb25lIG9mIHRob3NlIDUtNiBhcmVhIGRpcmVjdG9ycyAo d2l0aCBkcHJpdmUgaW4gbWluZCkmbmJzcDsmbmJzcDsgOy0pPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhvcGUgdGhpcyBoZWxwczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tw6lyaWM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5BZGQgJmx0O2FkZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUm9i IFNheXJlICZsdDtzYXlyZXJAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNk YXksIDkgT2N0b2JlciAyMDE5IGF0IDE1OjQxPGJyPg0KPGI+VG86IDwvYj5CYXJyeSBMZWliYSAm bHQ7YmFycnlsZWliYUBjb21wdXRlci5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5BREQgTWFpbGlu ZyBsaXN0ICZsdDthZGRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbQWRk XSBQcm9wb3NlZCBjaGFydGVyIGFuZCBCb0YgcmVxdWVzdCBmb3IgSUVURiAxMDY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFdlZCwg T2N0IDksIDIwMTkgYXQgODozMSBQTSBCYXJyeSBMZWliYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJh cnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyBXaG8gd3JvdGUgdGhlIGNoYXJ0 ZXI/IFNob3VsZG7igJl0IHRoZSBCb0YgcHJvcG9uZW50cyBiZSAxLTMgaW5kaXZpZHVhbHMsIHJh dGhlciB0aGFuIGEgbWFpbGluZyBsaXN0Pzxicj4NCjxicj4NClRoYXQncyBhIGZhaXIgcXVlc3Rp b24uJm5ic3A7IFRoZSBhbnN3ZXJzIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYW5rIHlvdSBmb3IgdGhlIHJlc3BvbnNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 YnI+DQpTbyBpZiBpdCBoZWxwcywgY29uc2lkZXIgJnF1b3Q7dGhlIElFU0cmcXVvdDsgYXMgdGhl IGNoYXJ0ZXIgcHJvcG9zYWwgd3JpdGVyczxicj4NCmFuZCAmcXVvdDs1IG9yIDYgQURzJnF1b3Q7 IGFzIHRoZSBCb0YgcHJvcG9uZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkl0IGRvZXMgbm90IGhlbHAuIENvdWxkIHRob3NlICZx dW90OzUgb3IgNiBBRHMmcXVvdDsgcHV0IHRoZWlyIG5hbWVzIG9uIHRoZSBwcm9wb3NhbD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dGhhbmtzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Um9iJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_72E8790563B145C38F1A921E7B753E68ciscocom_-- From nobody Wed Oct 9 06:57: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 DFC3B12011D for ; Wed, 9 Oct 2019 06:57:31 -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_HELO_NONE=0.001, 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 i-Y1dw9gw6Un for ; Wed, 9 Oct 2019 06:57:30 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 9DF08120115 for ; Wed, 9 Oct 2019 06:57:30 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id w12so5077749iol.11 for ; Wed, 09 Oct 2019 06:57:30 -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=Esc9uqVm7kGX4WJc1j7vQ/qr1sCTXLN0pAOzolMH2NU=; b=mHfaa59qpuYqig0lREPFgqYOnQKMKeSoYIV/g15VzzbGcbLVOPUC8rPEgP60OTupi4 WvodzjBE25Z/6AYRKBpPAwNoWg91O59S/kWfvJzm0NS6L7cCNEcK/rdLkfaFSj1vUiKT HzF4Bd/JJjSGewMd8S+CxQRZm2XXzTpZt+v4Qv+4AE0e2tbmT+feD5JgM6js/2bX+Fae E5DfrNRb5WzlZ/pfiMPbwOHnHv9sU0IMi7HRfARL4gaWYDj3sGWtia70MW6c/aOYIOje iBiO9gxkquK0IVJr2kG5ibh03btLmNRHv+cET29VYkGgCnkVEOdbxLimbEnzzLneo5L1 65wg== 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=Esc9uqVm7kGX4WJc1j7vQ/qr1sCTXLN0pAOzolMH2NU=; b=bK0FVJC+qm04VsNmA5uH0TliAI7w5/Y30HwzR81JuR+gDhUoXqYe1R39F3dCMuLDuP s4zgEo/8HUk0XLmp6j6Efx7tnqxW4hvYWkAvGsR72kifMGtz09B4CCeDVGRFoC0uk0K/ ZYosr7tOBrwx9A9FHhnKzEOH4JQ6UOVOM36uyUOp9s2n5NmHgYO7/Nh6qUL608w0b/jy o8L0iJS/bkW68BIHMkNKZ5yN2i/8+nNs8tiAze6fhZ0H1bgyTTCsRQ6/Lz0teDxC00V+ skr5C+rdwQVtaMwsls0dDUrZV/oaSuL3ejd5x8B+oWHd3dyczT9+ll4ZnsmZ4DA8F4Vo dNlA== X-Gm-Message-State: APjAAAVdHG273g0TnQ8IyV6Xh+skj2bexT7rFWlDqQ/JoD23zK9olRog SE2dacMyuC09zI8fgi6rwwUjYP6d/6snsqnByJ4= X-Google-Smtp-Source: APXvYqz+DlUD+j/b9xE7TZxln11cUyoSQ73y14lilyjqMGPOtTetHXAgRDunrHtBLglXK2O3Qj02AtjR2dvjogZTwIM= X-Received: by 2002:a6b:f40f:: with SMTP id i15mr3343072iog.54.1570629449938; Wed, 09 Oct 2019 06:57:29 -0700 (PDT) MIME-Version: 1.0 References: <72E87905-63B1-45C3-8F1A-921E7B753E68@cisco.com> In-Reply-To: <72E87905-63B1-45C3-8F1A-921E7B753E68@cisco.com> From: Rob Sayre Date: Wed, 9 Oct 2019 20:57:18 +0700 Message-ID: To: "Eric Vyncke (evyncke)" Cc: Barry Leiba , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000006ffa1c05947aaaa2" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 13:57:32 -0000 --0000000000006ffa1c05947aaaa2 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 8:56 PM Eric Vyncke (evyncke) wrote: > Rob > > > > There is no secret obviously: > Why not just put your names on the form? thanks, Rob --0000000000006ffa1c05947aaaa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 8:56 PM Eric Vynck= e (evyncke) <evyncke@cisco.com&= gt; wrote:

Rob

=C2=A0

There is no secret obviously:


Why not just put your names on the form?
<= /div>

thanks,
Rob
--0000000000006ffa1c05947aaaa2-- From nobody Wed Oct 9 07:05:16 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 98F05120154 for ; Wed, 9 Oct 2019 07:05:14 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 8IWTqaNfXIWU for ; Wed, 9 Oct 2019 07:05:12 -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 340A8120142 for ; Wed, 9 Oct 2019 07:05:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pGFK367jz3WV; Wed, 9 Oct 2019 16:05:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570629909; bh=Pwdyib2yrfenJy+Fp0nXFPvJXn8IOp0GWbXj9jcXPIg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kboVBsVXwP7BAewrjQGffplxDn1Ve7PLg8I0e1Mc1t8DZevQTeTxlPvbcXRuBe+mY XyOWqXZft3RVSpqSYhR3qYQzSQwyHQ58XyFMEIydsseywP60N47brK1yWLsG/UM+kp mndeocoJS1lWc6PQ5huG3hB/YqRSWp+6NjrC9iJk= 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 DmzUrHNvYT7B; Wed, 9 Oct 2019 16:05:07 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 9 Oct 2019 16:05:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C804E607F1DF; Wed, 9 Oct 2019 10:05:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C68BD23FE47; Wed, 9 Oct 2019 10:05:06 -0400 (EDT) Date: Wed, 9 Oct 2019 10:05:06 -0400 (EDT) From: Paul Wouters To: tirumal reddy cc: ADD Mailing list In-Reply-To: Message-ID: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 09 Oct 2019 14:05:15 -0000 On Tue, 8 Oct 2019, tirumal reddy wrote: > How and how would any enforcement system work for a variety of DNS > providers all over the world? ISPs? hotels? coffeeshops? Mobile > providers? Will there be an industry standard org? How will this > not devolve into government sanctioned mandatory DNS providers on > my mobile device? > > Users may or may not trust the attached network and the DNS server provided by the network (e.g, a public > network). It is similar to the way users disable VPN in specific trusted networks (e.g., Enterprise network) > and VPN is enabled by default in all other networks.   The user can already do that, without any help from the local network. If someone configures a VPN or a DoT/DoH, they do not need the local network for anything except passing a captive portal. I don't understand what you are adding here. Trust relationships of networks are: 1) I don't need to trust them, so I don't 2) I am forced to trust them, so I do. In the case of an enterprise network like 2) they can already pre-install the CA certs I need to trust on connecting to the network (see the IETF network do something similar there) > No. If the privacy requirements of the endpoint are not met, the DNS client can discard using the discovered > DNS server in the attached network, and connect to a public DNS resolver meeting the endpoint privacy > preserving data policy requirements.  Again, it is the other way around. Users should not need or want to trust the local network. My laptop mostly connects to completely unknown networks with zero trust _or_ a trusted enterprise network. What are these networks that a user should "trust to filter or log their DNS for them" ? > The proposed mechanism also helps the DNS client to automatically learn updates to the privacy claims by a DNS > server and avoids the need for users to periodically manually review the privacy statement.  Again, this is fixing a problem that I do not think exists. Why should I trust or not trust this network with DNS to begin with? Their privacy policy update will not change that for me. Either, they were already too weak for me to trust, so I don't care about their DNS privacy policy update, or I trusted them already, in which case it seems I trust them more than my own trusted DNS - AKA I'm forced to trust them (an enterprise network). > The privacy policy information helps make the decision whether the DNS provider can be trusted or not.  No it does not. It can only tell me when I for sure cannot trust them. Since I did not audit their logging, I can never be sure to trust them. It's like saying a privacy policy will select whether I use HTTP:// or HTTPS://. That is not the question. The question is why would I ever use HTTP:// ? > I'm still not convinced this statement is wrong. And additionally can > see some serious harmful effects into mandatory censorship if this kind > of system becomes mandatory on people's devices. > > I disagree, the proposal helps the user to choose a DNS server that best supports the desired privacy > policies. I either have a really good DNS provider that I fully trust up my sleeve, or I don't. If I do, I don't need the local network one. If I don't, I have no choice but the use the local network one. > DNS clients do not need to fallback to clear text DNS, and can use the DoT/DoH server provided by > the local network. Then why should I ever take a risk that this local network has a privacy policy that does not actually match its implementation? > Further, it also provides a mechanism to securely signal to the DNS client that the > attached network performs DNS filtering.  You cannot signal securely unless I have a trust anchor already on my device that would be used. If this is a CA-type store of hundreds of trust anchors, I cannot really trust them for this decision over a personally selected known safe choice. If it is enterprise specific, we already have mechanisms in place for securely obtaining updated DNS mechanisms. Like via VPN using RFC 8598. Paul From nobody Wed Oct 9 07:13: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 4F9E5120818 for ; Wed, 9 Oct 2019 07:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 FEe1-heyct8j for ; Wed, 9 Oct 2019 07:13:08 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 9CE9B12080E for ; Wed, 9 Oct 2019 07:13:08 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id b19so5312275iob.4 for ; Wed, 09 Oct 2019 07:13:08 -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=JigDivwcGx8djU4mpksjhK2GeeR5vBM4+vFhOqKPmB4=; b=eUgOeZXkm0M7fWF8yZ1fZJOIPFxtdnTUYSb9/1kRHKdjEMpZjJlu0Phje2rUDvo/8U hhKYNq6VC5aSI7a8Q4WWsQdbHb2yB/QLDMPReRm1xAtNyfukCMHAd3qYfSTDezGUcj0+ JDG+2ZCJ7oE+hb3q+mogjDIoTv/pcxvxlKioALpT6ckVIsO8tQ51eN1j6lsOkny5CM8R 5qiZGHqU99N39+ObrkMMTpG0qhUW6PLqq3LD8WUu69AnN9iEqi/EffYCWlpoUWVKXwOZ oa8o+/tTDn5QsRFrWMH1rN9w6v9Y4gz9aXoYvMKKTBVJtvFOj6ggPVSpopO3IFjWDv69 CxCA== X-Gm-Message-State: APjAAAWa8K206F7renPW4A8GtTYwd4Os47Ua80LkJcLe5L4Xkcb5eAsO GWqnhsRixBJITAzzKCo9ZxIGjDTsni/UZvF7rao= X-Google-Smtp-Source: APXvYqxpYwipFlNfNVNyGuBKJNMYM8y8X8JqnaG0ZDvOvmTQz98QnTQCV69HOFcRX9Z2y0Vd+3lGKh8CVkleEElCtwk= X-Received: by 2002:a6b:e012:: with SMTP id z18mr3545854iog.266.1570630387655; Wed, 09 Oct 2019 07:13:07 -0700 (PDT) MIME-Version: 1.0 References: <72E87905-63B1-45C3-8F1A-921E7B753E68@cisco.com> In-Reply-To: From: Barry Leiba Date: Wed, 9 Oct 2019 16:12:55 +0200 Message-ID: To: Rob Sayre Cc: "Eric Vyncke (evyncke)" , ADD Mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:13:09 -0000 > Why not just put your names on the form? Working on it; we're in the middle of a meeting right now, but I will fix it after. Barry From nobody Wed Oct 9 07:17: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 7C493120854 for ; Wed, 9 Oct 2019 07:17:05 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH58tEbd-rbu for ; Wed, 9 Oct 2019 07:17:03 -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 448AF120841 for ; Wed, 9 Oct 2019 07:17:03 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id j31so3649851qta.5 for ; Wed, 09 Oct 2019 07:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mbYhLCmeUPJjpZ0Fab7hn8guZ0xCzu7n0sqTTAmgmj4=; b=w2tFAg7jLDqiO5NupZ57JVLG0jnfItg3mxno3yaYPA8o5SDjk22OYLz/hRe4vPOhsv MZxhn8pmiT2Nrqk4hafB5wvlG9BHXc271ilSVO5rxigZX8dq8k7iJKUs0rleFTROTpkt IP4JqR7iRBZpgvjUAwundKU1fQ51wzOohwdlvor3R36EFO26BkeIYnbXWDTIVgxBnzRr vDqUovFjPvBcjoBs495nrKvk2XhznteDm4tiPskuFW5LowEkid3p9Mw+4p8LurSbLeLm eRok7b5yuHOVG+nqcB3/m1He2l7rr5V/ILa0u3HOsGh2KF47MXZDcNrW9gHAM1hENTWI pOqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mbYhLCmeUPJjpZ0Fab7hn8guZ0xCzu7n0sqTTAmgmj4=; b=U/0dow3vaeypX22rxwPQ0BTIieCS/JHh3vEquMp17yu0RHkLv2JK4e1T8ZyJHq41kZ V6r1h/EnAU4prRWN4iV9SOgFVStxfe1LwIA3z3DaqJcQ1X0LYtViXucMyUfHi2ElRBnB YThdWRv0qjszSxmIbXRx6ncTobcsR2TeAFalK5bcaVPI7+AVNWewCdwXGo5e/6XyoZXP waOyaNtuBBV8npsBZd+mBmbliSORs0+FtJcTdqTtFdYgg1E1oOLlC0sXDLuIFuGq3fNw 0LzuVhVgCcyOa6YfDiAEmUb5SpnrQ+U4XeavpbYPQ+bMCsgpP4YorC7MqkWZe1HWuZLG JjgQ== X-Gm-Message-State: APjAAAVUlL+xthhDu8JghQoSCvl+H9KvQNhSIHPTLItriVbiaE3Rfk8a PotOjpUHArC//q+xVI3PW6DyQRZy3Is= X-Google-Smtp-Source: APXvYqxbCcDQd4VAuvtbNm09bA7hNfe72omIUL3oelL5eLuIJbvOSrrrf6cF4Y4ZKLta9BezAZVl9w== X-Received: by 2002:ac8:48d9:: with SMTP id l25mr3742337qtr.1.1570630621853; Wed, 09 Oct 2019 07:17:01 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id s50sm1274660qth.92.2019.10.09.07.17.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 07:17:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 9 Oct 2019 10:16:59 -0400 Message-Id: <7B345BCE-F23A-47F7-95EB-2201F57F84E7@fugue.com> References: Cc: add@ietf.org In-Reply-To: To: Barry Leiba X-Mailer: iPhone Mail (17A850) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:17:11 -0000 If the proposal was half baked due to hurry, maybe the right approach is to w= ait until March. If you really think it=E2=80=99s urgent, you could do it as= a virtual BoF in January. That=E2=80=99s what the IESG would say to me if I= proposed something that was too rushed. =20 Are you going easier on yourselves than you would on an outsider? What is t= he rush? Is there some goal that you are pushing to achieve that justifies t= his rush? At present, the charter does not even discuss some of the most important use= cases for dns services configured by the network operator, particularly the= ones that involve surveillance. And we=E2=80=99ve had endless discussions o= n the exact topic of the proposed BoF here on the ADD mailing list with no e= vidence of consensus on the topics in the proposed charter.=20 With that in mind, why does the IESG consider this a good use of meeting tim= e? We already had this BoF in Montreal. We know there is no consensus on the= se topics. Can you make brief, crisp elevator pitch on why this is worth the= IETF=E2=80=99s time? > On Oct 9, 2019, at 09:31, Barry Leiba wrote: >=20 > =EF=BB=BF >>=20 >> Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 indivi= duals, rather than a mailing list? >=20 > That's a fair question. The answers are: >=20 > - The IESG write the charter proposal as something to float to the communi= ty. >=20 > - We took longer than we would have liked to get it done, and we > wanted to be sure we had it ready for discussion as soon as possible, > and to be sure we had a reasonable placeholder for BoF approval > (today). That was sloppy, and I'm sorry for that, but we also did not > have time to get it socialized and to have people signed up as > proponents and possible chairs yet. >=20 > So if it helps, consider "the IESG" as the charter proposal writers > and "5 or 6 ADs" as the BoF proponents. >=20 > Barry >=20 >> On Wed, Oct 9, 2019 at 10:55 AM Rob Sayre wrote: >>=20 >>> On Wed, Oct 9, 2019 at 2:39 PM Barry Leiba wro= te: >>>=20 >>>=20 >>> I realize that the charter proposal isn't going to please everyone >>> (and perhaps will please no one), but it's something that, at a first >>> level of review, the IESG accepts and will likely want to move forward >>> with. >>=20 >>=20 >> Hi, >>=20 >> Who wrote the charter? Shouldn=E2=80=99t the BoF proponents be 1-3 indivi= duals, rather than a mailing list? >>=20 >> The proposed charter looks extremely misguided to me. But a proposal that= no one will put their name on doesn=E2=80=99t even deserve an argument. >>=20 >> thanks, >> Rob >>=20 >>=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Wed Oct 9 07:21: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 CEBD91200E0 for ; Wed, 9 Oct 2019 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 JLLbA8KI8mvh for ; Wed, 9 Oct 2019 07:21:35 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 B907E12006E for ; Wed, 9 Oct 2019 07:21:33 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id k25so1858907oiw.13 for ; Wed, 09 Oct 2019 07:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mm2MjotiYEaV9h58bdji+easpSQhSwT6ustIivVX8UE=; b=oqbtdicJiBYRCuP4kHcPX6M2O3X5ES+v9o4nRKMtw9Bs2V0YasblNM3t6d+dygvhZA fYWwnWExfU6nnPMc5ylW76U8rC5qo+1lwBekH82wh9KI4CRvowVfoQoZStPlS2lCEETz M9CkqyAl+z/IV/3p4UOvtBvBJpyfySpZjLrV3M6LkKxzFkm7YxyIKoUjyx8BmnqJZu35 kIKg5o6+cbj3PxMjoOzNwnTYVKFcQ7HbeMzAbsKleGDPmcnbkpwQtLVmhvllrFU2W8B+ AVEUO9EW80zaWFlfvPqNcisI8JduS5ZMNGDaL/VLWNJfiba4YzP1UgNxNWnUpwHbTpaY 1dCg== 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=mm2MjotiYEaV9h58bdji+easpSQhSwT6ustIivVX8UE=; b=l1kwx4EvFUtFBl1W87IYCtkVS85SLp5wRu0I4/LfDto3RD+CJe+HFX9ImE7S42c/2Z m7baqJH7CP372jWSBTXfk9Nhasz/tIniWo15SlFdY7XnFDuw7N1K9Ed4+feOcWZBlyt+ CoTWh7sCKJl15Lfw6m4BH0rqNySFA6Ox4hL2F/hC8+kJffrQ2zdHqaQdPvrXSn/Tqhx/ N0Z37IbxgYO/GRVMxJikZH+vAOtBWkFuKpox6kQD/vGzIoAvrcCnoz9HHKLXFcWrXzUk bGcB18LNYzKbTwSuAKoLEwQnlhXACb0IKQ9mtsoLlGCIC+qG7JSU4rwPxHzlVMbARFTP g3jg== X-Gm-Message-State: APjAAAWXklr4ufL5QxdRXSWlgO37DiLnTMqf6aIgVSqNs3wCNETuoSg8 ofE5XhIIkp0cD6zqXH5TFJxWCsKOvHpaSXGCsXgdOoaQqpw= X-Google-Smtp-Source: APXvYqzXwBSQYPkOR6i1t6H07Ml250N8nhiWunAY1tLZOHK+ckqy8QoCQ4fWuhlmF9YI+vQaOkXk6ICrS2QchW/nJnI= X-Received: by 2002:aca:d5d5:: with SMTP id m204mr2480679oig.36.1570630892740; Wed, 09 Oct 2019 07:21:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 9 Oct 2019 10:21:20 -0400 Message-ID: To: add@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f788505947b00b9" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:21:38 -0000 --0000000000006f788505947b00b9 Content-Type: text/plain; charset="UTF-8" I think EKR is on the right track here. There is a bright line here between technology and deployment policy. The former we have some hope of progressing on, and there are meaty questions around how applications can discover local network capabilities and preferences in a way that is not open to abuse like the mechanisms we have today. On questions of the latter form, the entire history of this list, and the meeting that preceded it demonstrate, that there is very little hope of consensus. The charter right now has some of both. If this charter is to go forward, it should be refactored to focus on engineering questions, and avoid policy questions. In particular, the BCP item needs to be struck. --RLB On Wed, Oct 9, 2019 at 9:50 AM Eric Rescorla wrote: > > Barry, > > I took a first look at your proposed ABCD charter. Thanks for > proposing something. > > At a high level, I think there are some good areas for discussion > here, but they're going to get swamped by the inclusion of a bunch of > contentious topics we're not likely to get resolution on. > > I think this would be much stronger if it focused entirely > on technical matters on which there is at least some agreement, > specifically: > > - Signalling that the network has DoH support, who provides it, > and (potentially) what their policies are. > > - Signaling that the network has some kind of filtering policy > that might make the application think twice about using > DoH. > > - Something like the apple proposal that does "steering" of > traffic to the right resolver. > > Note that these mechanisms should generally not tell apps what > policies they should follow when they see these signals. > > > These seem to be on your list below. I think we should stay away from > anything that is about specifying best current practices because as > far as I can tell all but the most trivial ones (here is how to safely > run a TLS server or something) are contested. For instance, even > retention period has very strong views on both sides. > > > > Together, these developments may represent > > a set of shifts depending on how the new protocols are deployed: from > > cleartext to encrypted transports; from use of unique port numbers for > > DNS resolution to ports that support significant other traffic (e.g., > > HTTPS); from network operator control of DNS configuration to control by > > clients, third-party resolvers, or others; and from the use of a large, > > dispersed set of network operator resolvers to a smaller set of more > > centralized resolvers operated by other parties. > > The word "may" is doing a lot of work here. In particular, while I > realize that this centralization argument has been repeatedly raised, > it's not really a point of consensus. Consider that in the United > States, the ISP market is dominated by a very small number of players, > with two companies, Charter and Comcast, having the vast majority of > the market > ( > https://www.statista.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider/ > ) > Because residential customers generally use the ISP resolver, this > market is already highly centralized. It's true that there are a lot > of much smaller enterprise resolvers, but every major > application-level DNS rollout I have seen proposed attempts to > preserve that situation. > > > > > This potential set of shifts raises many questions given the long history > > and current status of DNS operational practices. Network operators have > > historically used DNS services for a variety of purposes beyond simple > > query resolution: to mitigate network and security threats, to enforce > > enterprise policy, to provide parental controls and other filters, and to > > comply with relevant laws and regulations, among others. > > This list of practices would be much more accurate if it included the > resolver-level DNS practices that we are trying to mitigate using DoH, > including NXDOMAIN synthesis and collection of user browsing history > data. > > > > Achieving these > > objectives while providing confidentiality and tamper-resistance will > > generally require that network operators shift to one of the available > > encrypted transports for their resolvers and that clients include > > configuration options to select them. > > This entirely misses the point, which isn't just to do a lot of encryption > but to provide security for the user. Just having network operators > transition to secure transports while continuing their current practices > does not address the issue. > > > > Specific initial areas of focus include: > > > > - Resolver discovery > > - Expression of resolver policy > > - Query routing in the presence of resolver choice > > - Best Current Practices for the deployment and operation of encrypted > DNS transport > > This seems like it leaves all of the contested issues firmly > in scope. I can't imagine how we're going to get consensus on > best current practices, when we can't even agree on the terms > for resolver selection. > > -Ekr > > On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba > wrote: > >> Hi, all, >> >> The IESG has worked up a proposal for a possible working group, which >> we're tentatively calling "ABCD", for "Application Behavior >> Considering DNS". We can discuss the charter proposal here, and >> expect to approve a working-group-forming BoF for Singapore. >> >> I realize that the charter proposal isn't going to please everyone >> (and perhaps will please no one), but it's something that, at a first >> level of review, the IESG accepts and will likely want to move forward >> with. >> >> See the proposal here: >> https://trac.tools.ietf.org/bof/trac/wiki/WikiStart >> >> I am also going to remove the moderation of this list for now. Let's >> see how that goes. Please continue being calm, thoughtful, and >> respectful (and thanks for having done that during the moderation >> period). >> >> Barry >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --0000000000006f788505947b00b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think EKR is on the right track he= re.=C2=A0

There is a bright=20 line here between technology and deployment policy.=C2=A0 The former we hav= e=20 some hope of progressing on, and there are meaty questions around how=20 applications can discover local network capabilities and preferences in a way that is not open to abuse like the mechanisms we have today.=C2=A0 On= =20 questions of the latter form, the entire history of this list, and the=20 meeting that preceded it demonstrate, that there is very little hope of=20 consensus.=C2=A0

The charter right now has so= me of both.=C2=A0 If this charter is to go forward, it should be refactored t= o=20 focus on engineering questions, and avoid policy questions.=C2=A0 In=20 particular, the BCP item needs to be struck.

= --RLB

On Wed, Oct 9, 2019 at 9:50 AM Eric Rescorla <ekr@rtfm.com> wrote:

Barry,

I took a first look at your proposed ABCD = charter. Thanks for
proposing something.

At a high level, I think= there are some good areas for discussion
here, but they're going to= get swamped by the inclusion of a bunch of
contentious topics we're= not likely to get resolution on.

I think this would be much stronge= r if it focused entirely
on technical matters on which there is at least= some agreement,
specifically:

- Signalling that the network has = DoH support, who provides it,
=C2=A0 and (potentially) what their polici= es are.

- Signaling that the network has some kind of filtering poli= cy
=C2=A0 that might make the application think twice about using
=C2= =A0 DoH.

- Something like the apple proposal that does "steerin= g" of
=C2=A0 traffic to the right resolver.
=C2=A0
Note that= these mechanisms should generally not tell apps what
policies they shou= ld follow when they see these signals.


These seem to be on your = list below. I think we should stay away from
anything that is about spec= ifying best current practices because as
far as I can tell all but the m= ost trivial ones (here is how to safely
run a TLS server or something) a= re contested. For instance, even
retention period has very strong views = on both sides.


> Together, these developments may represent> a set of shifts depending on how the new protocols are deployed: fro= m
> cleartext to encrypted transports; from use of unique port number= s for
> DNS resolution to ports that support significant other traffi= c (e.g.,
> HTTPS); from network operator control of DNS configuration= to control by
> clients, third-party resolvers, or others; and from = the use of a large,
> dispersed set of network operator resolvers to = a smaller set of more
> centralized resolvers operated by other parti= es.

The word "may" is doing a lot of work here. In particu= lar, while I
realize that this centralization argument has been repeated= ly raised,
it's not really a point of consensus. Consider that in th= e United
States, the ISP market is dominated by a very small number of p= layers,
with two companies, Charter and Comcast, having the vast majorit= y of
the market
(h= ttps://www.statista.com/statistics/217348/us-broadband-internet-susbcribers= -by-cable-provider/)
Because residential customers generally use the= ISP resolver, this
market is already highly centralized. It's true = that there are a lot
of much smaller enterprise resolvers, but every maj= or
application-level DNS rollout I have seen proposed attempts to
pre= serve that situation.



> This potential set of shifts rais= es many questions given the long history
> and current status of DNS = operational practices. Network operators have
> historically used DNS= services for a variety of purposes beyond simple
> query resolution:= to mitigate network and security threats, to enforce
> enterprise po= licy, to provide parental controls and other filters, and to
> comply= with relevant laws and regulations, among others.

This list of prac= tices would be much more accurate if it included the
resolver-level DNS = practices that we are trying to mitigate using DoH,
including NXDOMAIN s= ynthesis and collection of user browsing history
data.


> A= chieving these
> objectives while providing confidentiality and tampe= r-resistance will
> generally require that network operators shift to= one of the available
> encrypted transports for their resolvers and = that clients include
> configuration options to select them.

T= his entirely misses the point, which isn't just to do a lot of encrypti= on
but to provide security for the user. Just having network operatorstransition to secure transports while continuing their current practices<= br>does not address the issue.


> Specific initial areas of fo= cus include:
>
> - Resolver discovery
> - Expression of = resolver policy
> - Query routing in the presence of resolver choice<= br>> - Best Current Practices for the deployment and operation of encryp= ted DNS transport

This seems like it leaves all of the contested iss= ues firmly
in scope. I can't imagine how we're going to get cons= ensus on
best current practices, when we can't even agree on the ter= ms
for resolver selection.

-Ekr

On Wed, Oct 9, 2019 at 12:39 A= M Barry Leiba <barryleiba@computer.org> wrote:
Hi, all,

The IESG has worked up a proposal for a possible working group, which
we're tentatively calling "ABCD", for "Application Behav= ior
Considering DNS".=C2=A0 We can discuss the charter proposal here, and<= br> expect to approve a working-group-forming BoF for Singapore.

I realize that the charter proposal isn't going to please everyone
(and perhaps will please no one), but it's something that, at a first level of review, the IESG accepts and will likely want to move forward
with.

See the proposal here:
=C2=A0 =C2=A0 =C2=A0 https://trac.tools.ietf.org/= bof/trac/wiki/WikiStart

I am also going to remove the moderation of this list for now.=C2=A0 Let= 9;s
see how that goes.=C2=A0 Please continue being calm, thoughtful, and
respectful (and thanks for having done that during the moderation
period).

Barry

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000006f788505947b00b9-- From nobody Wed Oct 9 07:21: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 6AFED120840 for ; Wed, 9 Oct 2019 07:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMMEtmduvPlV for ; Wed, 9 Oct 2019 07:21:40 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 7FF3D120821 for ; Wed, 9 Oct 2019 07:21:40 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id u22so3609381qtq.13 for ; Wed, 09 Oct 2019 07:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ro/NYXuajEBsdir7XX/5jhZmoggjamXP/Vzz7toGDM4=; b=yuIBcyqxdX5Ko0kqXqB98XV0jF1GHfVUT/X6Pke/9yUUL6W6LbjsUOycwl1+7TJl4v Eh9l8E558qzelX2rNGSXsqHUv91Gnyg0gPROeYZk2BagUxjxcEA8poF4kg8xAwBxVuXt JtjzTCl2IkZIqwKImRs3Yfb9kNnmaax60qJvSu9KBE2F56rqsCtT4s6oLY+HUb4gmiVc vnB6mjbOryHqGJe3ZY+Hq+bwRv0CBYTY054r8CLw7LhwgG3LALkayT48l9UwAuN+A4OG R6Uj2Qm0SczpYcf20zsH4XKxU5B8/G+pwhJB07658hYGqEAij0jnaua2guMuhvBYjI2I hwzQ== 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=ro/NYXuajEBsdir7XX/5jhZmoggjamXP/Vzz7toGDM4=; b=iaZPVEimbJ5+lhJpnp1E4H8xgByyBfQYcgHeIBbhu+WjJJU9o8ogU4zQPUjKvPihld U2OzB0aSLCU/Ub2G6UKaK6YKdN0Y8zJ4+ZISckjMAsPyuENTmEjhEj7vL0MoF5Vr4nqa 80883m/bBqxK2lhV9pWc5qFX6h0gfz8hYrG3DB/VmxiulV+kdmt1dh3A6YzTUdCer7wK c/9UWAEXYxpj/g4birxLFZ6ovCL4cnTWUemTh8nMCt47AB0H3hxGifH4S5UJGt5rCpv+ s0voFrKpZ+FPbqZ0R49QlS0NOSiHNuwEQcvwZN55QermzRCuVTin6YybV7smzF3exVbv 6MKw== X-Gm-Message-State: APjAAAXfiBZuoWvOYpP1rPZbtM8YtaO2q2hoycTQPUAE+xHjFsz39s7j mLx+ZhuBkKpTVrc0smMeVIngIA== X-Google-Smtp-Source: APXvYqz9XAIOzP5FdOdhvbCNb7QYN0VQKCqB2AXrHUUXqJDi2mOD1YCvqdWZRkSuCdkMP93VWv8SFg== X-Received: by 2002:ac8:5203:: with SMTP id r3mr3975358qtn.16.1570630899540; Wed, 09 Oct 2019 07:21:39 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id c14sm1171439qta.80.2019.10.09.07.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 07:21:25 -0700 (PDT) From: Ted Lemon Message-Id: <3B9A1D39-CCDC-47FE-81C9-37880E2AF7A1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F48291CD-B70D-4A34-B6A2-A2FCA5A5FF8E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.13\)) Date: Wed, 9 Oct 2019 10:21:22 -0400 In-Reply-To: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.net> Cc: Eric Rescorla , Barry Leiba , ADD Mailing list To: Jari Arkko References: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.net> X-Mailer: Apple Mail (2.3594.4.13) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:21:48 -0000 --Apple-Mail=_F48291CD-B70D-4A34-B6A2-A2FCA5A5FF8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 9, 2019, at 9:50 AM, Jari Arkko wrote: > But I also think that we have to say something about privacy, = pervasive monitoring and centralisation issues. =46rom my perspective if = we work on this topic at all, we=E2=80=99d be not doing our duty if we = didn=E2=80=99t consider those aspects. Who is the =E2=80=9Cwe=E2=80=9D here, Jari? If it=E2=80=99s the IAB, = then you don=E2=80=99t need a BoF. Go write down what you think and = share it with us as an IAB statement or IAB RFC. I think this would be = a useful thing to do. But I don=E2=80=99t think there=E2=80=99s a = =E2=80=9Cwe=E2=80=9D in the IETF that has a consensus position on this, = so even if =E2=80=9Cwe=E2=80=9D should say something about this, it=E2=80=99= s clear to me that there is no something we can agree on that we could = say. --Apple-Mail=_F48291CD-B70D-4A34-B6A2-A2FCA5A5FF8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 9, 2019, at 9:50 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
But I also think that we have to say something about privacy, = pervasive monitoring and centralisation issues. =46rom my perspective if = we work on this topic at all, we=E2=80=99d be not doing our duty if we = didn=E2=80=99t consider those = aspects.

Who= is the =E2=80=9Cwe=E2=80=9D here, Jari?   If it=E2=80=99s the IAB, = then you don=E2=80=99t need a BoF.  Go write down what you think = and share it with us as an IAB statement or IAB RFC.  I think this = would be a useful thing to do.   But I don=E2=80=99t think = there=E2=80=99s a =E2=80=9Cwe=E2=80=9D in the IETF that has a consensus = position on this, so even if =E2=80=9Cwe=E2=80=9D should say something = about this, it=E2=80=99s clear to me that there is no something we can = agree on that we could say.

= --Apple-Mail=_F48291CD-B70D-4A34-B6A2-A2FCA5A5FF8E-- From nobody Wed Oct 9 07:24: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 63243120121 for ; Wed, 9 Oct 2019 07:24: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_HELO_NONE=0.001, 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 h4gQz4SyOGLL for ; Wed, 9 Oct 2019 07:24:28 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 3302F1200E0 for ; Wed, 9 Oct 2019 07:24:28 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id b19so5402387iob.4 for ; Wed, 09 Oct 2019 07:24:28 -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=LQpzy2qsAsvlOIzCQB02e+cW46B09B58zQ8H6WIu6r4=; b=NHYykIuyECbasj/NBr9dZI6CmpyDlqiuRvGyPna1o//5UVcg0xqZrdVOkznqOl93yW +RRK45Vp0s0O1mXzhaqz0uTaEpB7y9+Ya9cZalHdbNbTX8PGqVFGqmw0oHq+Iw5HL2j/ 7QEK8qbMzxNyd7Fg5u6K6/sFVMVqB/pSd1qpdwHCKnL3S+qUblDJ3HMDGvU6fkfQMT9y d5C5+VB5WIOKRkx1czwH7w++FV8+yLZRJt+HcDrXE36xoE7VLPBYfd3d/wC8PEYrRZCL dBnwmz42B1hgZtHzSHZVjlWrh7srIV5NFht/PKX2ruKmbhDj66oNxbA+xruUjDED8ySR eoaQ== 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=LQpzy2qsAsvlOIzCQB02e+cW46B09B58zQ8H6WIu6r4=; b=S/VSHzcDAhjNV8BXXdN+wjEg31Omgk/rbt4G3Gl0w/3Pjsf86bkyNKZDL0grn48+BG UmjakRRtbwsju/DrSQRaWTjheJdRwkOprXzIvhUUBcZ2vwTgQmuRp8yd5lmjQWxxJWLM +430WuchSsVWj0U7ThZLu7x7M7YOF+LQw8XtQ8EKXLgikULkhj9KRQKqER8JyrlFQIis 6nEBIjxN2Juh6hW4Mfo0rtUUMtjDYT+l6rDAgg49xEzbvjrQGNZfWKzvwmFT3bctGuqN dxcfkfK2cFXltA4Ng1tpJHq+XZ2L8uPE6vTzXlZ2mXjuKsJuD4UuJ6eqQMhYjxO5qlVw 5ReA== X-Gm-Message-State: APjAAAU3onZ+yWbaI8iEHrlYtiWO0gRhj1LDOZvkC6OwOTy2IHUmYqZI YbF3zTmSv7bUXm9vvmwr5crxSzOGZR8SLKKnIKwe85+CPOu0tA== X-Google-Smtp-Source: APXvYqychvG3TemZCieoE6rgnni31Z+S/FFIUI72VuNiXofWgoj/eymOai/N9uXKAyW0B4Q9csmqIdD48SpS6GXoPzc= X-Received: by 2002:a6b:f90f:: with SMTP id j15mr2261587iog.257.1570631067450; Wed, 09 Oct 2019 07:24:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 21:24:16 +0700 Message-ID: To: Richard Barnes Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000d943dd05947b0aa9" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:24:29 -0000 --000000000000d943dd05947b0aa9 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 9:21 PM Richard Barnes wrote: > > If this charter is to go forward, it should be refactored to focus on > engineering questions, and avoid policy questions. In particular, the BCP > item needs to be struck. > Fully agree. thanks, Rob --000000000000d943dd05947b0aa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 9:21 PM Richard Ba= rnes <rlb@ipv.sx> wrote:

=C2=A0If this charter is to go forward, it should be r= efactored to=20 focus on engineering questions, and avoid policy questions.=C2=A0 In=20 particular, the BCP item needs to be struck.
=

Fully agree.

thanks,
Rob=C2=A0
--000000000000d943dd05947b0aa9-- From nobody Wed Oct 9 07:25: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 747AE1200E0 for ; Wed, 9 Oct 2019 07:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXzKvQGtVgi7 for ; Wed, 9 Oct 2019 07:25: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 E9AD212006E for ; Wed, 9 Oct 2019 07:25:25 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id p10so2361041qkg.8 for ; Wed, 09 Oct 2019 07:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JEHt3ulTY3Uu+F4Iy9lkugedS23FpR/Z21UIKQQWiLM=; b=K/yRq2Wg3Y23KxLJTe6MHxMMPVEsz6uqkX9J2vhDQ7SoPsq3Jx2fAjEcSQkiY1Xg0m SPymnqPnFxiM1s9wXKwmZjhO78VrGFIPCNerQ9vjGljAe/HKyYjE6qb56pfvkCMDY95x mzPKjm/VrR6Dx9NoBmU0ggQKP7ooA8ruOR46+v1j6NWG/D5y2ahF/pRDG3xxRFvKoPUC fXGZHFxHWOLN3WXl5OOpqPAJK8+Xce3WRgb5gvttYpPCKFOavLzCvIFX+Ifs0IR3iMVi sevDc5rvCyfa0+H0Z4n4iYEB/zeqKqo0xWDzB3sf98HLyVoP+4yLzYmDPGo/sGA766/W 5Zmg== 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=JEHt3ulTY3Uu+F4Iy9lkugedS23FpR/Z21UIKQQWiLM=; b=OxnhkN9t6Q/GnC0dmDldpyWOppAy5/LI8EcypmS8wiXm533KcoC4GMeYIC2k0sO5eM OLqVCy+d0PCFJSr5mzY7Wh84nn1DKirEMsAg3p46Um/KyA0MJxvSRTQY4LimqUVZocli yIlg74AMseG0B6WI6jzvig+Wqk+D+Z75XfInq71+ZMmAW2JTipEIbaxyuU8p6x0yvntH ThhgCVh75eMNPvioq4JoEYkzfK7+lU16rCp3H2D4ThwxKXdhilYZvEcp+aXvapYtTgxj RlSzIHzGwrhb2DdhG4Dvz6uSc7YxYH2ICFOygsIuMDHS+YJs6d1F2xm9yUFak5HnPObc 32mA== X-Gm-Message-State: APjAAAU1cADR/k42dYNIVb5jWqsunAfPb888Au9FdxsOHelDur5BI59J flrZKRJGvdaBmLqaU0x8acBPUA== X-Google-Smtp-Source: APXvYqyOJO2S2wFJ9l4RuC2ubU2LBajRJ2pBGPGK0r+C5RjJ8H2M1EjfVOhcn+uRN9tGRvr2tvPRyw== X-Received: by 2002:a37:8ec5:: with SMTP id q188mr3751902qkd.495.1570631125035; Wed, 09 Oct 2019 07:25:25 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id r7sm993290qkf.124.2019.10.09.07.25.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 07:25:21 -0700 (PDT) From: Ted Lemon Message-Id: <47B8E41F-B887-4867-A1B1-FC7D5A09334C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C859B0A6-F114-4876-BF66-B8E3190D208D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.13\)) Date: Wed, 9 Oct 2019 10:25:19 -0400 In-Reply-To: <0B781E27-8B8A-4718-8269-73E8A9DCE46A@hopcount.ca> Cc: Dave Lawrence , ADD Mailing list To: Joe Abley References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> <23964.55791.591141.356687@gro.dd.org> <0B781E27-8B8A-4718-8269-73E8A9DCE46A@hopcount.ca> X-Mailer: Apple Mail (2.3594.4.13) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 14:25:28 -0000 --Apple-Mail=_C859B0A6-F114-4876-BF66-B8E3190D208D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 9, 2019, at 9:36 AM, Joe Abley wrote: > Another way of interpreting that statement is that perhaps the only = botnets we know about are the ones that use DNS to find C&C controllers; = it could well be that there are significant numbers of botnets that do = it some other way that we can't see. True. However, such botnets would have to be pretty smart to be able = to hide effectively: they would have to avoid operating on hosts on = research networks, so that their traffic isn=E2=80=99t seen by = researchers. I=E2=80=99m not sure how they=E2=80=99d do that, but = it=E2=80=99s an interesting question to investigate (sort of off-topic = for ADD, of course!). --Apple-Mail=_C859B0A6-F114-4876-BF66-B8E3190D208D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 9, 2019, at 9:36 AM, Joe Abley <jabley@hopcount.ca> = wrote:
Another way = of interpreting that statement is that perhaps the only botnets we know = about are the ones that use DNS to find C&C controllers; it could = well be that there are significant numbers of botnets that do it some = other way that we can't see.

True.   However, such botnets would have = to be pretty smart to be able to hide effectively: they would have to = avoid operating on hosts on research networks, so that their traffic = isn=E2=80=99t seen by researchers.   I=E2=80=99m not sure how = they=E2=80=99d do that, but it=E2=80=99s an interesting question to = investigate (sort of off-topic for ADD, of course!).

= --Apple-Mail=_C859B0A6-F114-4876-BF66-B8E3190D208D-- From nobody Wed Oct 9 07:28:02 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 1D884120104 for ; Wed, 9 Oct 2019 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 p_oYZOsOTYcx for ; Wed, 9 Oct 2019 07:27:58 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 6B1AF12006E for ; Wed, 9 Oct 2019 07:27:58 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id c6so5300677ioo.13 for ; Wed, 09 Oct 2019 07:27:58 -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=fT+aXyPz1ouflyuoyW/3igIMBQEsuYYhkDlWzBoSEv4=; b=Llzzuzv6CBznQ+vV7VkS268PbpiKRDNkpupEU6MHXOXR3gSLWV+0j9mSmhnlCcdRvW qpFAolIbk9jAudl0WiCcANaF36k6XhC/ydfwsDNF0oEHW89av/+62+qFUtXa3n19PC1V f3dARa6Hwdl3qaToyr3oZsNo//cX6wEPc5DdI= 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=fT+aXyPz1ouflyuoyW/3igIMBQEsuYYhkDlWzBoSEv4=; b=JgMwOf378VvO+oO2Ek0CsR22pUMPtkHYx4ZJ7JiGPNcIFHM1pBqGj4QIjtaVr0D4iA lvVwZduCBTCPqNK3g5A2vjqotwFOpfD8sTUx1uCj1ugkfOi31KPrcH7EaBdrpGAcv0mj VbN6m2A6vdoE4yt21k75maR2vtyuCxODmWcDewfwyi0JnBvqC1fr8DyWFRSouuH8FV3a Q4kOym2UVZ6O9eOCQc4kBUDwxhmPdh01Yr9YBmHabbnwE3ob4iDlWk22KObjgO6Yk0OM wEmWGP+ksF11R3+RPHQUZ1Yy/FqdFpz266DywSQZITR2jBEW6pcYcpm+7LSBYJo9MpZc gBOg== X-Gm-Message-State: APjAAAVckkNDgKQDh/J/KIJOu0gnhRhGpeV+LJWCxlfPoCYJwOZ9l7er Wqpb09eGwwXRFAXmzzmqh5A2/j42DPmgY1pc X-Google-Smtp-Source: APXvYqwUaVyP0eQYA+rcfYFMCpP2TcNXjz4xuCJcUCrUS+shLBfwBG3dXJzTV0faLwDNd56fYjiUfw== X-Received: by 2002:a5e:9202:: with SMTP id y2mr3583316iop.300.1570631277412; Wed, 09 Oct 2019 07:27:57 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:9040:dbfa:a425:dac9? ([2607:f2c0:e786:128f:9040:dbfa:a425:dac9]) by smtp.gmail.com with ESMTPSA id m4sm849730ioc.39.2019.10.09.07.27.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 07:27:56 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4EAAAEE3-49D8-4061-B82B-0627A3D40E8F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Wed, 9 Oct 2019 10:27:54 -0400 In-Reply-To: <47B8E41F-B887-4867-A1B1-FC7D5A09334C@fugue.com> Cc: Dave Lawrence , ADD Mailing list To: Ted Lemon References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> <23964.55791.591141.356687@gro.dd.org> <0B781E27-8B8A-4718-8269-73E8A9DCE46A@hopcount.ca> <47B8E41F-B887-4867-A1B1-FC7D5A09334C@fugue.com> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 14:28:00 -0000 --Apple-Mail=_4EAAAEE3-49D8-4061-B82B-0627A3D40E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Oct 2019, at 10:25, Ted Lemon wrote: > On Oct 9, 2019, at 9:36 AM, Joe Abley > wrote: >> Another way of interpreting that statement is that perhaps the only = botnets we know about are the ones that use DNS to find C&C controllers; = it could well be that there are significant numbers of botnets that do = it some other way that we can't see. >=20 > True. However, such botnets would have to be pretty smart to be able = to hide effectively: they would have to avoid operating on hosts on = research networks, so that their traffic isn=E2=80=99t seen by = researchers. Perhaps they tunnel everything over HTTPS to Cloudflare, hiding in plain = sight :-) Joe --Apple-Mail=_4EAAAEE3-49D8-4061-B82B-0627A3D40E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 9 Oct 2019, at 10:25, Ted Lemon <mellon@fugue.com> wrote:

On Oct 9, 2019, at 9:36 AM, Joe Abley = <jabley@hopcount.ca> wrote:
Another way of interpreting that statement is that perhaps = the only botnets we know about are the ones that use DNS to find C&C = controllers; it could well be that there are significant numbers of = botnets that do it some other way that we can't see.

True.   However, such botnets would have to be pretty = smart to be able to hide effectively: they would have to avoid operating = on hosts on research networks, so that their traffic isn=E2=80=99t seen = by researchers.

Perhaps they tunnel everything over HTTPS to = Cloudflare, hiding in plain sight :-)


Joe

= --Apple-Mail=_4EAAAEE3-49D8-4061-B82B-0627A3D40E8F-- From nobody Wed Oct 9 07:30: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 483DF12010E for ; Wed, 9 Oct 2019 07:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYgG9WUiAOJD for ; Wed, 9 Oct 2019 07:30:33 -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 1C28912006E for ; Wed, 9 Oct 2019 07:30:33 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id 3so3758317qta.1 for ; Wed, 09 Oct 2019 07:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1YnML/xNiZcBuCcKDxO73a8Y+OUHRH55mF4nBbQraLk=; b=qGPkpFF/xvCJWhq6sflI8Q9k8XXi6PbYVvty4Fwr5yYj3cMPXQ4YuY0UW0E8pz6iTX Ts+35xfPNtwGSwiQI0O7dHU3wmHPtqyNQQdDMO3o318jpw2JLNk16i3G3cd5paEh6YCO EtqXYj1Cv4SaugOfhUZozCOI7HmJv7LG6A99XmlPYW2sgKNw06hDvY/Z0yGdWs4UE783 IU4stHlYnVs6tnanywBjPM4aj20us/con5LJnmN+aNrBEHdgt5FatMc5YOkQNs8CrDhV o9W9w/QNLQOVUqSKB3HR+2C6OZRZV4A+UviMNjvsIYSiPLjRXHEYY0d8TDRHoq5SARGG 2Tnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1YnML/xNiZcBuCcKDxO73a8Y+OUHRH55mF4nBbQraLk=; b=AtPEOfvnnp8LFcRRkJY9llCM37P5oEGjBJV7EtwWgeu8KfyD8VL3BknvXFydLKxeLd G+g1iQcBqjfq5ByFYtvPM1A9jYZyi2LXhe6OzIW022SaNjpVG7jhjdFNei8bSQSdX+Kb vX00seTRPIXr/xcddl9eduvf5W/zGN6rLjek2pCZHHGT2EB+u1jMTjTra3pk3Dy3ph0c iX5G1mYh3bIWXbZq3evSNJRYOk3+Y9CLCRCniJYEw/Qef0hcgjGqOpTDvHQVgO87DvMy Xmeupls+iPIEzLMbql9btBSwZY8JB7pkSOSEXCoXy3qsFkEidF0DgZRuJrzCOYFeCdF8 pS2A== X-Gm-Message-State: APjAAAWQbsCnUEEczTNBpMnm518Wt/WJ/pFXL+hg33flasiwV38Wacz0 12WPzh0kIMxPtoytZLlPrC7pJQ== X-Google-Smtp-Source: APXvYqy/IxHQPgYagxiw8j1fBvETq9Cx18B7mVV+5d7op0bV/+PWIa4eKhNDDMs67r5PaZ837vwdag== X-Received: by 2002:a0c:e6e7:: with SMTP id m7mr4024913qvn.138.1570631432228; Wed, 09 Oct 2019 07:30:32 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id y4sm971208qkl.107.2019.10.09.07.30.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 07:30:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C4C5AD7E-14F8-4C8F-A4A3-53E64596C3C2 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 9 Oct 2019 10:30:30 -0400 Message-Id: References: Cc: Dave Lawrence , ADD Mailing list In-Reply-To: To: Joe Abley X-Mailer: iPhone Mail (17A850) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 14:30:35 -0000 --Apple-Mail-C4C5AD7E-14F8-4C8F-A4A3-53E64596C3C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think this could still be noticed. You=E2=80=99d need intelligence on the d= evice noticing that there are surreptitious connections being made.=20 > On Oct 9, 2019, at 10:27, Joe Abley wrote: >=20 > =EF=BB=BFOn 9 Oct 2019, at 10:25, Ted Lemon wrote: >=20 >>> On Oct 9, 2019, at 9:36 AM, Joe Abley wrote: >>> Another way of interpreting that statement is that perhaps the only botn= ets we know about are the ones that use DNS to find C&C controllers; it coul= d well be that there are significant numbers of botnets that do it some othe= r way that we can't see. >>=20 >> True. However, such botnets would have to be pretty smart to be able to= hide effectively: they would have to avoid operating on hosts on research n= etworks, so that their traffic isn=E2=80=99t seen by researchers. >=20 > Perhaps they tunnel everything over HTTPS to Cloudflare, hiding in plain s= ight :-) >=20 >=20 > Joe >=20 --Apple-Mail-C4C5AD7E-14F8-4C8F-A4A3-53E64596C3C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think this could still b= e noticed. You=E2=80=99d need intelligence on the device noticing that there= are surreptitious connections being made. 

<= blockquote type=3D"cite">On Oct 9, 2019, at 10:27, Joe Abley <jabley@hopc= ount.ca> wrote:

=EF=BB=BFOn 9 Oct 2019, at 10:25, Ted Lemon <mellon@fugue.com> wrote:

On Oct 9, 2019, at 9:36 AM, Joe Abley <jabley@hopcount.ca> wrote:
Another way of interpreting= that statement is that perhaps the only botnets we know about are the ones t= hat use DNS to find C&C controllers; it could well be that there are sig= nificant numbers of botnets that do it some other way that we can't see.

True.   However, such botnets would have to be pr= etty smart to be able to hide effectively: they would have to avoid operatin= g on hosts on research networks, so that their traffic isn=E2=80=99t seen by= researchers.

Perhap= s they tunnel everything over HTTPS to Cloudflare, hiding in plain sight :-)=


Joe

= --Apple-Mail-C4C5AD7E-14F8-4C8F-A4A3-53E64596C3C2-- From nobody Wed Oct 9 07:41: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 132AC120110 for ; Wed, 9 Oct 2019 07:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 3WLN0lhfXFwU for ; Wed, 9 Oct 2019 07:41:17 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4148312010E for ; Wed, 9 Oct 2019 07:41:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8BD83660169; Wed, 9 Oct 2019 17:41:16 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv56nVeSupHa; Wed, 9 Oct 2019 17:41:14 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 86DE66600AF; Wed, 9 Oct 2019 17:41:14 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 9 Oct 2019 16:41:13 +0200 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:41:19 -0000 Richard, I realise that it is easier to ignore the deployment models. And I = don=E2=80=99t imagine that we=E2=80=99d have unanimous opinion about = deployment models. Certainly the NSAs of the world and few others that = have very specific deployments depend on benefits from centralised = models :-) But, should that drive IETF opinion on an important change in = Internet infrastructure.=20 I wouldn=E2=80=99t entirely rule out broader IETF rough consensus on = what=E2=80=99s good. We could find out, perhaps. And I think we should care about pervasive monitoring, in this and other = topics. Jari From nobody Wed Oct 9 07:52: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 CA6C71200E0 for ; Wed, 9 Oct 2019 07:52:40 -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, HTML_MESSAGE=0.001, 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=cooperw.in header.b=LVq/KyV3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pYLHTO/b 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 N3VakqROM06E for ; Wed, 9 Oct 2019 07:52:38 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF5812008B for ; Wed, 9 Oct 2019 07:52:37 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 17C9218A; Wed, 9 Oct 2019 10:52:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 09 Oct 2019 10:52:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=BteZMfbJExhgZhR5xUFsFLN Z/ZJUt3608Q/cEPsyLBU=; b=LVq/KyV3z2r+TKOYWSoKs/1p5/9G2qaovGjFbRr mKVrKlxqh1poqCqkBWYYxj3/3vEP6NRvXVcSlS1ug/xZ3TNpWMUvhRGvjGmr5+K2 KBaobtYGkTsFCjVf8KGeQzXienAXTLvCEGwFV2S13owK6uVKqpEQzQIzIPqGNpBi pFMUF5wcBrwelqtAa14rcTdAIIYF4z0dQfeZCLrc1xKDiZk0pIOmBDZ4ztvACpi1 UpyIUTJJxw9mXWL+ZFzTwTLsb0F0eiXKB2d8LOj7X+3dh1H4A8ne3pbewx1V74IP D4j6lELQv46VLtIdJpqGdKG9v+mGBKRIgaUf7pCUKySjqpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=BteZMf bJExhgZhR5xUFsFLNZ/ZJUt3608Q/cEPsyLBU=; b=pYLHTO/bYIwbroyd1YUh6Q V9dpXijrYB1HBzhBwXSpbwth659pWmq0O2mNYtXk5itaS0tcC0NNYv6mFPi/cMkH 0BIau4HLIXD1y/pB5KfkdqHNIxsNO4eOZn4FsRM6KIbRcFxjt2i4vyFcHrvyE7ly 4tw/xYqS9LDFwOz3Libhku8X2GsBnF43haSj6G+jKY4sYGSo9kz/iHRunUWJrnB0 jJsrsFx1N0iH6gpO2TTGBQklO7CHht3ny2mf8rSeypBGYDeksR5uds3sEc4LdXfs FukcdBm+uyVPcAEHhdXBCLPcUWft7lYIJRPZke8uEF879YwJj6XxjDGihnY2H/3w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedugdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrghinh epihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkedvnecurfgrrhgrmhep mhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: from [10.82.168.16] (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id C26D6D60062; Wed, 9 Oct 2019 10:52:35 -0400 (EDT) From: Alissa Cooper Message-Id: <0F11A08C-F93F-43F9-A3EF-3D1E378D4073@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B0BB8C6-D820-463C-9777-CD484974AED1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 9 Oct 2019 16:52:33 +0200 In-Reply-To: Cc: Joe Abley , Barry Leiba , ADD Mailing list To: Rob Sayre References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 14:52:41 -0000 --Apple-Mail=_4B0BB8C6-D820-463C-9777-CD484974AED1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, When the IESG was discussing this, I wrote up the text below. The = structure and some of the text made it into the version Barry shared. =E2=80=94 Application Behavior Considering DNS (ABCD) DNS over TLS (DoT) [RFC 7858], DNS over DTLS [RFC8094], and DNS over = HTTPS (DoH) [RFC 8484] provide confidentiality and tamper-resistance to = thwart on-path attacks against DNS queries flowing between clients and = recursive resolvers. Along with the deployment of these new transports, = various application providers have been exploring having the application = configure its own DNS services rather than using DNS services configured = by the network operator. (The working group considers a network operator = to include Internet service providers, enterprises, and any businesses = that provide network access.) Together, these developments may represent = a set of shifts depending on how the new protocols are deployed: from = cleartext to encrypted transports, from use of unique port numbers for = DNS resolution to ports that support significant other traffic (e.g., = HTTPS), and from network operator control of DNS configuration to = control by clients, third-party resolvers, or others. This potential set of shifts raises many questions given the long = history and current status of DNS operational practices. Network = operators have historically used DNS services for a variety of purposes = beyond simple query resolution: to mitigate network and security = threats, to enforce enterprise policy, to provide parental controls and = other filters, and to comply with relevant laws and regulations, among = others. To the extent that the presence of encrypted DNS transports or = changes in DNS configuration control or both create barriers to = achieving the objectives that underlie these practices, this working = group is the venue within the IETF to work on engineering and = operational solutions.=20 This working group is focused on specifying protocols, guidance, and = best practices to support the smooth operation of encrypted DNS = transports across diverse networks with potentially diverse and changing = arrangements concerning where the control of DNS service configuration = is located. Specific initial areas of focus include but are not limited = to: - Resolver discovery and selection - Expression of resolver policy - Support for split-horizon DNS environments - Mechanisms to facilitate testing of new configurations This working group will coordinate with the DNSOP (OPS Area) and DPRIVE = (INT Area) working groups, and all last-call announcements (including = Working Group Last Calls issued by the chairs) will be copied to all = three working groups to ensure thorough and careful review. The working = group will also coordinate with the Security Area, and will be assigned = a security advisor. =E2=80=94 Best, Alissa > On Oct 9, 2019, at 3:51 PM, Rob Sayre wrote: >=20 >=20 >=20 > On Wed, Oct 9, 2019 at 8:48 PM Joe Abley > wrote: > Hi Rob, >=20 > On 9 Oct 2019, at 09:40, Rob Sayre > wrote: >=20 > >> So if it helps, consider "the IESG" as the charter proposal writers > >> and "5 or 6 ADs" as the BoF proponents. > >=20 > > It does not help. Could those "5 or 6 ADs" put their names on the = proposal? >=20 > Can you explain why this is important? >=20 > I don't mean to imply it's not; I'm just trying to understand your = question. >=20 > You ask a totally fair question. >=20 > I think the charter is misguided and wrote that "a proposal that no = one will put their name on doesn=E2=80=99t even deserve an argument."=20 >=20 > So, I just asked (again) whether someone would put their name on it. >=20 > thanks, > Rob > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_4B0BB8C6-D820-463C-9777-CD484974AED1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rob,

When the IESG = was discussing this, I wrote up the text below. The structure and some = of the text made it into the version Barry shared.

=E2=80=94

Application Behavior = Considering DNS (ABCD)

DNS over TLS (DoT) = [RFC 7858], DNS over DTLS [RFC8094], and DNS over HTTPS (DoH) [RFC 8484] = provide confidentiality and tamper-resistance to thwart on-path attacks = against DNS queries flowing between clients and recursive resolvers. = Along with the deployment of these new transports, various application = providers have been exploring having the application configure its own = DNS services rather than using DNS services configured by the network = operator. (The working group considers a network operator to include = Internet service providers, enterprises, and any businesses that provide = network access.) Together, these developments may represent a set of = shifts depending on how the new protocols are deployed: from cleartext = to encrypted transports, from use of unique port numbers for DNS = resolution to ports that support significant other traffic (e.g., = HTTPS), and from network operator control of DNS configuration to = control by clients, third-party resolvers, or others.

This potential set of shifts raises many questions given the = long history and current status of DNS operational practices. Network = operators have historically used DNS services for a variety of purposes = beyond simple query resolution: to mitigate network and security = threats, to enforce enterprise policy, to provide parental controls and = other filters, and to comply with relevant laws and regulations, among = others. To the extent that the presence of encrypted DNS transports or = changes in DNS configuration control or both create barriers to = achieving the objectives that underlie these practices, this working = group is the venue within the IETF to work on engineering and = operational solutions. 

This working = group is focused on specifying protocols, guidance, and best practices = to support the smooth operation of encrypted DNS transports across = diverse networks with potentially diverse and changing arrangements = concerning where the control of DNS service configuration is located. = Specific initial areas of focus include but are not limited to:

- Resolver discovery and selection
- Expression of resolver policy
- Support for = split-horizon DNS environments
- Mechanisms to facilitate = testing of new configurations

This working = group will coordinate with the DNSOP (OPS Area) and DPRIVE (INT Area) = working groups, and all last-call announcements (including Working Group = Last Calls issued by the chairs) will be copied to all three working = groups to ensure thorough and careful review.  The working group = will also coordinate with the Security Area, and will be assigned a = security advisor.

=E2=80=94

Best,
Alissa


On Oct 9, 2019, at 3:51 PM, Rob Sayre <sayrer@gmail.com> = wrote:



On Wed, Oct 9, 2019 at 8:48 PM Joe = Abley <jabley@hopcount.ca> wrote:
Hi Rob,

On 9 Oct 2019, at 09:40, Rob Sayre <sayrer@gmail.com> wrote:

>> So if it helps, consider "the IESG" as the charter proposal = writers
>> and "5 or 6 ADs" as the BoF proponents.
>
> It does not help. Could those "5 or 6 ADs" put their names on the = proposal?

Can you explain why this is important?

I don't mean to imply it's not; I'm just trying to understand your = question.

You ask a totally fair = question.

I = think the charter is misguided and wrote that "a proposal that no one = will put their name on doesn=E2=80=99t even deserve an = argument." 

So, I just asked (again) whether someone would put their = name on it.

thanks,
Rob
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_4B0BB8C6-D820-463C-9777-CD484974AED1-- From nobody Wed Oct 9 08:04: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 1A2D912010E for ; Wed, 9 Oct 2019 08:04: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_HELO_NONE=0.001, 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 gGN_EcgJTYaa for ; Wed, 9 Oct 2019 08:04:13 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 B7B471200E7 for ; Wed, 9 Oct 2019 08:04:13 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id b136so5726479iof.3 for ; Wed, 09 Oct 2019 08:04:13 -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=aznqQ46HSyndoBHYrYQj050xsIb2YDDSehJh+OIgEyU=; b=DbidYQeVyzXYxvjrwiImM+9FLlTsUi/z3VdSmbPQP0I3On90k3xere8iUBYKPzhOFQ O2RdXgoAHh8S6FFUGH9FIMHm0n2N0ri6ThcvYdZB4EXINpRla3GLCKuSESYSk7l8ZLwK P+lwKWqRwtlZj+lU0oYREzVylZAuDlE32KhtnbbNXWyEjyR5TIbCYymMpyultZm2ZP7q YIKV1SOuAF3dk6IuTxFtM3Z6q6bmwCup/rUk1yGDiINfekU4wmhsr40Ak8O7UB2F7y/b RgJfDR8d9g90/imx89S9KLNEvTmt5BPzGXQt/+5SHd9wGMbSX5+xmR5C52geSV44v7q5 smBQ== 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=aznqQ46HSyndoBHYrYQj050xsIb2YDDSehJh+OIgEyU=; b=UVyWh6r6vLCOnDWTX4omhOB+CUV3+TOvlEP3eYpLb8vqMWkXKuXkrVtoDcJMJsaLGV bV61KSa+m5p1b+FyVyF4MuML8fEsBT2eNc7WJ8WZYkaqujr6Z2QWXx77wc5K3MwRPA3y 0FKM9UAGqKsObjpVyBIKOmkUNjaBrijgNxmDuxW46/KTSL4vp3L6gZlGyoPWk+XgbPCc 7qAaQniUYyPHbIJR6rbGt8uDaUZgc6mWhK/EOotv1DIKnhRwwvHciTiSZI1XniZ1n6E3 4ZbFAbUmoCYiFXehHqE7Y+8NpYy9N5z8kXKwoxQErh9/oExVi1QAMGGv4M9+n2D7Mz/8 NYrQ== X-Gm-Message-State: APjAAAW43OLQBKK8uITqDWbRfwy+oK6o2BmK0Wy8fwO/nfXGZT+gKBay n8l/GBVhUtFt9Pe6XJYD7vy8w3YPZ5MNFV/m1b8= X-Google-Smtp-Source: APXvYqyoUaFyteyC3LJGyMLbn035H7VKDRcHuSZ4ut36qhwRp7D+2nhwnOkKltDQYYmnskEKRwVdx+72pblJOwjP0Pc= X-Received: by 2002:a02:c646:: with SMTP id k6mr3573463jan.53.1570633452908; Wed, 09 Oct 2019 08:04:12 -0700 (PDT) MIME-Version: 1.0 References: <0F11A08C-F93F-43F9-A3EF-3D1E378D4073@cooperw.in> In-Reply-To: <0F11A08C-F93F-43F9-A3EF-3D1E378D4073@cooperw.in> From: Rob Sayre Date: Wed, 9 Oct 2019 22:03:58 +0700 Message-ID: To: Alissa Cooper Cc: Joe Abley , Barry Leiba , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000008779905947b9984" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 15:04:19 -0000 --00000000000008779905947b9984 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alissa, Thank you for sharing that text. A light edit to your contribution might say: "Network operators have historically mis-used DNS for a variety of purposes..." The "mis-" prefix was obviously added by me. But should the IETF take those use cases seriously? I think all the shady traffic is on the "dark web" now, anyway. thanks, Rob On Wed, Oct 9, 2019 at 9:52 PM Alissa Cooper wrote: > Hi Rob, > > When the IESG was discussing this, I wrote up the text below. The > structure and some of the text made it into the version Barry shared. > > =E2=80=94 > > Application Behavior Considering DNS (ABCD) > > DNS over TLS (DoT) [RFC 7858], DNS over DTLS [RFC8094], and DNS over HTTP= S > (DoH) [RFC 8484] provide confidentiality and tamper-resistance to thwart > on-path attacks against DNS queries flowing between clients and recursive > resolvers. Along with the deployment of these new transports, various > application providers have been exploring having the application configur= e > its own DNS services rather than using DNS services configured by the > network operator. (The working group considers a network operator to > include Internet service providers, enterprises, and any businesses that > provide network access.) Together, these developments may represent a set > of shifts depending on how the new protocols are deployed: from cleartext > to encrypted transports, from use of unique port numbers for DNS resoluti= on > to ports that support significant other traffic (e.g., HTTPS), and from > network operator control of DNS configuration to control by clients, > third-party resolvers, or others. > > This potential set of shifts raises many questions given the long history > and current status of DNS operational practices. Network operators have > historically used DNS services for a variety of purposes beyond simple > query resolution: to mitigate network and security threats, to enforce > enterprise policy, to provide parental controls and other filters, and to > comply with relevant laws and regulations, among others. To the extent th= at > the presence of encrypted DNS transports or changes in DNS configuration > control or both create barriers to achieving the objectives that underlie > these practices, this working group is the venue within the IETF to work = on > engineering and operational solutions. > > This working group is focused on specifying protocols, guidance, and best > practices to support the smooth operation of encrypted DNS transports > across diverse networks with potentially diverse and changing arrangement= s > concerning where the control of DNS service configuration is located. > Specific initial areas of focus include but are not limited to: > > - Resolver discovery and selection > - Expression of resolver policy > - Support for split-horizon DNS environments > - Mechanisms to facilitate testing of new configurations > > This working group will coordinate with the DNSOP (OPS Area) and DPRIVE > (INT Area) working groups, and all last-call announcements (including > Working Group Last Calls issued by the chairs) will be copied to all thre= e > working groups to ensure thorough and careful review. The working group > will also coordinate with the Security Area, and will be assigned a > security advisor. > > =E2=80=94 > > Best, > Alissa > > > On Oct 9, 2019, at 3:51 PM, Rob Sayre wrote: > > > > On Wed, Oct 9, 2019 at 8:48 PM Joe Abley wrote: > >> Hi Rob, >> >> On 9 Oct 2019, at 09:40, Rob Sayre wrote: >> >> >> So if it helps, consider "the IESG" as the charter proposal writers >> >> and "5 or 6 ADs" as the BoF proponents. >> > >> > It does not help. Could those "5 or 6 ADs" put their names on the >> proposal? >> >> Can you explain why this is important? >> >> I don't mean to imply it's not; I'm just trying to understand your >> question. >> > > You ask a totally fair question. > > I think the charter is misguided and wrote that "a proposal that no one > will put their name on doesn=E2=80=99t even deserve an argument." > > So, I just asked (again) whether someone would put their name on it. > > thanks, > Rob > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > > > --00000000000008779905947b9984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alissa,

Thank you for sharing = that text. A light edit to your contribution might say:

= "Network operators have historically mis-used DNS for a variety of pur= poses..."

The "mis-" prefix was= obviously added by me. But should the IETF take those use cases seriously?= I think all the shady traffic is on the "dark web" now, anyway.<= /div>

thanks,
Rob


On Wed, Oct 9, 2019 at 9:52 PM Alissa Cooper <alissa@cooperw.in> wrote:
On Oct 9, 2019, at 3:51 PM, Rob Sayre = <sayrer@gmail.com<= /a>> wrote:


On Wed, = Oct 9, 2019 at 8:48 PM Joe Abley <jabley@hopcount.ca> wrote:
Hi Rob,

On 9 Oct 2019, at 09:40, Rob Sayre <sayrer@gmail.com> wrote:

>> So if it helps, consider "the IESG" as the charter propo= sal writers
>> and "5 or 6 ADs" as the BoF proponents.
>
> It does not help. Could those "5 or 6 ADs" put their names o= n the proposal?

Can you explain why this is important?

I don't mean to imply it's not; I'm just trying to understand y= our question.

You ask a totally fair qu= estion.

I think the charter is misguided and wrote= that "a proposal that no one will put their name on doesn=E2=80=99t e= ven deserve an argument."=C2=A0

So, I just as= ked=C2=A0(again) whether someone would put their name on it.

=
thanks,
Rob
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
<= /blockquote>

--00000000000008779905947b9984-- From nobody Wed Oct 9 08:08: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 776381200C5 for ; Wed, 9 Oct 2019 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 PQnwMRxTN-jR for ; Wed, 9 Oct 2019 08:08:49 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 61F01120110 for ; Wed, 9 Oct 2019 08:08:49 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id k9so2031702oib.7 for ; Wed, 09 Oct 2019 08:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fvldo+wlLOpPXJ+7iIjTJGVKvekSiJ5GGZ05Y4QbV+o=; b=TdwfZ2kjpiqyqyTk6+V9SJ5TTy/gjGM2upaucyZAMKLryghUBz2HpbROnmbwsvsOk4 T3RmLQHzlvAlvtzi3pr8xuEiDlGyzAvCDth3YOsCGI/uYbNs/KxO3Wu5uwePaKf0r0YE JuYC1ezczOIo8XGk0w5lBkuU/Xy2vWGcKohXhT/6TIbvs9yJcn1ZRKbUQRR9pmIeoO0O iX+S+kwhjlhTQJPVJkz4prx3FaSVYfOPkgWiowm57nyS6mqMZ+RQeVC0drJTdRkA1iRV aM+WL2ZtKtqDZ3uRgOcgHCDbI/ibohbG1nQhrDputNDh0BgngKqOu2m3fcPSm4V/Ltk/ 71JQ== 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=fvldo+wlLOpPXJ+7iIjTJGVKvekSiJ5GGZ05Y4QbV+o=; b=Ph5RIRRfrZSuXgLw8IsuwqbPfm+a9QSRcXiyAC3bs3supI8N3krMDVM/AiL3Z3A9Bt SOb8H3Dz9qPY0WmD2sn54afIrc+RawCM8Qo9jvgVUNmy5XquRxj4j9ex0ZsjlpAmsdbA iT5tRypQMMsVrMiEcDygJ7uikBeogDVWRO86mM7YUVKddHyyS//k83yF5hRDVIl1lXUV V5p1CrixwEeg1FE9Iq/ukJWQEgpnTSFucYZbMUakB1/Q5QOEE6QrqV+VNjwh8WHCyCMt 1C0EQuMJa0nDHHBSyRP8eObyoH1talgkBzd0mOG/Z5S2Z38doL4u/yQAK504AEvsACE4 UUdQ== X-Gm-Message-State: APjAAAXK5MK1mkpBA/m3ayvnqDWladQ8JET1o8gE4LQBIEVakCs7enw0 gnnwtUCUJ5Q+moqJf5sutUATt8SMCwMEnvlu8avv9A== X-Google-Smtp-Source: APXvYqxRtYNf/Pvxe8q97Wd89XPUFSGi1CR485pT9eKX8SJOg6+0U7udVPmA0h/i1SD0hsnuPosft3S5XOjU0g1JfGw= X-Received: by 2002:aca:1c03:: with SMTP id c3mr2556921oic.135.1570633724916; Wed, 09 Oct 2019 08:08:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 9 Oct 2019 11:08:32 -0400 Message-ID: To: Jari Arkko Cc: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000418ede05947ba935" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 15:08:54 -0000 --000000000000418ede05947ba935 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jari, Of course I agree that we should care about pervasive monitoring. But it's far from clear which of the deployment options is more resilient against that threat. The Snowden revelations indicated NSA interference at both ISPs and cloud providers. As for ruling out broader IETF rough consensus -- This hopefulness has been expressed several times in this thread. As far as I can tell, all the data are on the other side. --Richard On Wed, Oct 9, 2019 at 10:41 AM Jari Arkko wrote: > Richard, > > I realise that it is easier to ignore the deployment models. And I don=E2= =80=99t > imagine that we=E2=80=99d have unanimous opinion about deployment models.= Certainly > the NSAs of the world and few others that have very specific deployments > depend on benefits from centralised models :-) But, should that drive IET= F > opinion on an important change in Internet infrastructure. > > I wouldn=E2=80=99t entirely rule out broader IETF rough consensus on what= =E2=80=99s good. > We could find out, perhaps. > > And I think we should care about pervasive monitoring, in this and other > topics. > > Jari > > --000000000000418ede05947ba935 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jari,

Of course I agree t= hat we should care about pervasive monitoring.=C2=A0 But it's far from = clear which of the deployment options is more resilient against that threat= .=C2=A0 The Snowden revelations indicated NSA interference at both ISPs and= cloud providers.

As for ruling out broader IETF r= ough consensus -- This hopefulness has been expressed several times in this= thread.=C2=A0 As far as I can tell, all the data are on the other side.

--Richard


On Wed, Oct 9= , 2019 at 10:41 AM Jari Arkko <j= ari.arkko@piuha.net> wrote:
Richard,

I realise that it is easier to ignore the deployment models. And I don=E2= =80=99t imagine that we=E2=80=99d have unanimous opinion about deployment m= odels. Certainly the NSAs of the world and few others that have very specif= ic deployments depend on benefits from centralised models :-) But, should t= hat drive IETF opinion on an important change in Internet infrastructure. <= br>
I wouldn=E2=80=99t entirely rule out broader IETF rough consensus on what= =E2=80=99s good. We could find out, perhaps.

And I think we should care about pervasive monitoring, in this and other to= pics.

Jari

--000000000000418ede05947ba935-- From nobody Wed Oct 9 08:57: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 E1FF3120121 for ; Wed, 9 Oct 2019 08:57: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_HELO_NONE=0.001, 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 6OSRHgGabMWW for ; Wed, 9 Oct 2019 08:57:27 -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 4E838120145 for ; Wed, 9 Oct 2019 08:57:22 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id BFE1B5F42AF9; Wed, 9 Oct 2019 17:57:20 +0200 (CEST) Received: from [192.168.2.190] (p4FC210FD.dip0.t-ipconnect.de [79.194.16.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 0DC4B5F40E4B; Wed, 9 Oct 2019 17:57:19 +0200 (CEST) From: "Ralf Weber" To: "Eric Rescorla" Cc: chris.box@bt.com, "ADD Mailing list" Date: Wed, 09 Oct 2019 17:57:18 +0200 X-Mailer: MailMate (1.13r5655) Message-ID: <1D2F035B-A34D-42E8-BBED-8DB962B04BE1@fl1ger.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 15:57:29 -0000 Moin! On 9 Oct 2019, at 15:51, Eric Rescorla wrote: > On Wed, Oct 9, 2019 at 6:36 AM wrote: >> Please point me to an operator that is arguing for the continuing of >> NXDOMAIN monetisation. > > > Arguing or not, it continues to happen, at least on T-mobile. I assume you mean T-Mobile US as it is not happening for me at T-Mobile in Germany. But that aside Browsers are still monetising sending search results to a search provider they choose when I enter something in the Omnibox that most browsers today have. How is that different from ISP monetisation? Now I don’t like both and wish we would not have these Omniboxes, but instead an URL and search box with a possibility to choose a search provider before my search and associated personal identifiable cookie goes there. So long -Ralf From nobody Wed Oct 9 09:11: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 BCD97120876 for ; Wed, 9 Oct 2019 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adn5YjV7pD_d for ; Wed, 9 Oct 2019 09:11:19 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450: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 C414C120877 for ; Wed, 9 Oct 2019 09:11:18 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id u3so2090689lfl.10 for ; Wed, 09 Oct 2019 09:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=baVAFUAKBloa8PRe9wT3h1SN2/uptEpft1CDcNYgoXg=; b=GbclGHqmVbbjuhEjOBEiezpQH56Jj4bfLNHMRe8cHuDeRrszQvdFVbzjdBku5uO514 SKc0sFb9uz59X/gHB09M7jscJVljGfE3bvFgwEp0hWTLKtgixkHLbAcHOOR6PoMXYFxz aVMnHqvqUxH9C1TRiBeJU8gNX+s4sskKnAAhtlgfnntzN9p1eWATgtqltqX8ft8nLBNq 4uD5eJfmMaISXhnD+GaKYA8jS0w7pFjqJlaLXdOsrmYpuePQlKF9MMqSypxNu9SYRgYm kabYB5Q5NN7xd8GP+PfPlTGtoTt/FJq62wEE15Ll6BIychxQnt0I7gKXsl/Y6onwyaoM fCIw== 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=baVAFUAKBloa8PRe9wT3h1SN2/uptEpft1CDcNYgoXg=; b=IUioFIZikPgqZQSo1KJkrWHFWgdb1RKsTRNWt6brAiOpoxDoqiQA7vyYZW0sHLzX4F hoodAYgkhBDD8/QRjbUzeQ/vHbEaoB3t75bWju+WFk1u3VfSMNp6veIwnUEmocJBqQNP /vE0C24HTWogRwBQx+oXf+2IIEkevCGvIg4KruEZu+Of8kBMNHiJd6Tcdd27yhXkzWHE h8sawa0/ch5peMvKmQ4TcEVtPfoeW8Eq/Ci6UIJrsyc8Id5fZWbNpZGzuTzOULvjBokQ iH2eiU6TSVTGnbeXjVXNl+ifwaFGkNVU7iV/LtBmc6S4LeA9IVWwuCeG1J8YZVEZdHVf 2SGw== X-Gm-Message-State: APjAAAWs4GWo9nbXh+r+IhOQA9cIUpg+XtkRMZsrute0bqmVrv7G5vll O6/6RQjc1s9N4BIUBsyoVB1f4MgYiFY6MmXYrWgupw== X-Google-Smtp-Source: APXvYqztUlIDq947fKNzVD6I920fZMKa9dCKqFsCC/w9w5emWVxycFtoAw1aGR9zfjbhumTxDDQZb08s6vBKe7PRKYc= X-Received: by 2002:a19:7404:: with SMTP id v4mr2555747lfe.129.1570637476958; Wed, 09 Oct 2019 09:11:16 -0700 (PDT) MIME-Version: 1.0 References: <1D2F035B-A34D-42E8-BBED-8DB962B04BE1@fl1ger.de> In-Reply-To: <1D2F035B-A34D-42E8-BBED-8DB962B04BE1@fl1ger.de> From: Eric Rescorla Date: Wed, 9 Oct 2019 09:10:40 -0700 Message-ID: To: Ralf Weber Cc: chris.box@bt.com, ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e2ac0505947c887b" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 16:11:21 -0000 --000000000000e2ac0505947c887b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 8:57 AM Ralf Weber wrote: > Moin! > > > On 9 Oct 2019, at 15:51, Eric Rescorla wrote: > > > On Wed, Oct 9, 2019 at 6:36 AM wrote: > >> Please point me to an operator that is arguing for the continuing of > >> NXDOMAIN monetisation. > > > > > > Arguing or not, it continues to happen, at least on T-mobile. > I assume you mean T-Mobile US as it is not happening for me at T-Mobile > in Germany. > Yes. I do not know what T-mobile does in Germany. Now I don=E2=80=99t like both and wish we would not have these Omniboxes, b= ut > instead an URL and search box with a possibility to choose a search > provider before my search and associated personal identifiable cookie > goes there. > I'm not quite sure what you're looking for here, but Firefox does allow you to select your search provider both globally and on a per-search basis. The former is done via Preferences > Search. The latter is done by having a list of search providers at the bottom of the suggestions offered by the AwesomeBar= , and you can click to send the searches there. Note that you'll need to turn off Search Suggestions because that's implemented by sending your partial queries to the selected search provider. This is also done in Preferences > Search. -Ekr --000000000000e2ac0505947c887b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 8:57 AM Ralf W= eber <dns@fl1ger.de> wrote:
<= /div>
Moin!


On 9 Oct 2019, at 15:51, Eric Rescorla wrote:

> On Wed, Oct 9, 2019 at 6:36 AM <chris.box@bt.com> wrote:
>> Please point me to an operator that is arguing for the continuing = of
>> NXDOMAIN monetisation.
>
>
> Arguing or not, it continues to happen, at least on T-mobile.
I assume you mean T-Mobile US as it is not happening for me at T-Mobile
in Germany.

Yes. I do not know what T-m= obile does in Germany.


Now I don=E2=80=99t like both and wish we would not have these Omniboxes, b= ut
instead an URL and search box with a possibility to choose a search
provider before my search and associated personal identifiable cookie
goes there.

I'm not quite sure what= you're looking for here, but Firefox does allow you to
selec= t your search provider both globally and on a per-search basis. The former<= /div>
is done via Preferences > Search. The latter is done by having= a list of
search providers at the bottom of the suggestions offe= red by the AwesomeBar,
and you can click to send the searches the= re. Note that you'll need to turn
off Search Suggestions beca= use that's implemented by sending your partial
queries to the= selected search provider. This is also done in Preferences > Search.

-Ekr

--000000000000e2ac0505947c887b-- From nobody Wed Oct 9 09:22: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 A9FC112085B for ; Wed, 9 Oct 2019 09:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 LRfDAu19fnfD for ; Wed, 9 Oct 2019 09:22:36 -0700 (PDT) Received: from smtp118.iad3a.emailsrvr.com (smtp118.iad3a.emailsrvr.com [173.203.187.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50C812085E for ; Wed, 9 Oct 2019 09:22:35 -0700 (PDT) X-Auth-ID: bgreene@senki.org Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id E3D194F8D for ; Wed, 9 Oct 2019 12:22:34 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [10.0.0.246] (c-73-15-67-108.hsd1.ca.comcast.net [73.15.67.108]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 09 Oct 2019 12:22:35 -0400 From: Barry Greene Content-Type: multipart/signed; boundary="Apple-Mail=_42E4E7FE-5951-412D-97BE-7A80B7D9365D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 9 Oct 2019 09:22:32 -0700 References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> <23964.55791.591141.356687@gro.dd.org> To: ADD Mailing list In-Reply-To: <23964.55791.591141.356687@gro.dd.org> Message-Id: <8DE3BAFF-9D6B-494E-89CA-6C5F89FA10D6@senki.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 16:22:38 -0000 --Apple-Mail=_42E4E7FE-5951-412D-97BE-7A80B7D9365D Content-Type: multipart/alternative; boundary="Apple-Mail=_B05E26A8-B2EA-402A-8447-AF6A9DE0F4B0" --Apple-Mail=_B05E26A8-B2EA-402A-8447-AF6A9DE0F4B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Ted Lemon writes: >> Why do you think botnets bother to use DNS to find C&C controllers, >> even though DNS has been being used as a way to mitigate malware for >> years? If they could do it some other way, wouldn=E2=80=99t they = have done so? The reaction by the security community is the core reason miscreants = moved to DNS and DGA. We (security operators in ISPs around the world), = can RTBH a malware C&C in minutes. =46rom 2002 - 2006 we were = whack-a-mole C&Cs all over the world. BGP was our #1 security tool. Then the miscreants shifted their C&C to DGAs and Fast-Flux. This is = when using the DNS resolver as a security tool was dusted off and = deployed. We then had some malware shift to IPv6 C&C (around 2009ish). = The Netflow tools were not set up to spot this activity. Then those were = addressed. Then we started seeing malware systems using Peer-to-Peer. = Mitigations where were a combination of policy, DNS resolver filters, = and BGP are used on those. The problem I have with this discussion is people thinking they know = what they are talking about when it comes to battling malware, botnets, = and miscreant activities. We need all the tools in our battle against = the miscreants. The miscreant problem is NOT going away with technology. = It is a Internation Justice issue which is outside of the IETF=E2=80=99s = function. --Apple-Mail=_B05E26A8-B2EA-402A-8447-AF6A9DE0F4B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Ted Lemon writes:
Why = do you think botnets bother to use DNS to find C&C controllers,
even though DNS has been being used as a way to mitigate = malware for
years?   If they could do it some = other way, wouldn=E2=80=99t they have done so? 

The reaction by the security = community is the core reason miscreants moved to DNS and DGA. We = (security operators in ISPs around the world), can RTBH a malware = C&C in minutes. =46rom 2002 - 2006 we were whack-a-mole C&Cs all = over the world. BGP was our #1 security tool.

Then the miscreants shifted their = C&C to DGAs and Fast-Flux. This is when using the DNS resolver as a = security tool was dusted off and deployed. We then had some malware = shift to IPv6 C&C (around 2009ish). The Netflow tools were not set = up to spot this activity. Then those were addressed. Then we started = seeing malware systems using Peer-to-Peer. Mitigations where were a = combination of policy, DNS resolver filters, and BGP are used on = those. 

The= problem I have with this discussion is people thinking they know what = they are talking about when it comes to battling malware, botnets, and = miscreant activities. We need all the tools in our battle against the = miscreants. The miscreant problem is NOT going away with technology. It = is a Internation Justice issue which is outside of the IETF=E2=80=99s = function. 


= --Apple-Mail=_B05E26A8-B2EA-402A-8447-AF6A9DE0F4B0-- --Apple-Mail=_42E4E7FE-5951-412D-97BE-7A80B7D9365D 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----- iQEzBAEBCgAdFiEEdoGA/YBcwd1ud+j1VW6TcBa/RfMFAl2eCUkACgkQVW6TcBa/ RfMvGQgAhroPhC5zZQYYisD7ODpFKX5h1V0BebD8pUga+Rak4fY9rp+kJgv0T5hf Gl701FhPz6T5fyDMGxAbQLkskGfeR3xrKxhPXsWCXYhymYg1N/5Y+FUdi9o6ZpfD mGMKllNUeaXSDXgMhdKhu5FjqXzUlYxAKcBg7pCKuqOjdHgHtfP8seaGdTfBKE56 QYw1A3H56/0v9PyHs7XpmpKC1civ4ThwnnfjMr30wY5sxnu+twZviPK/CK5cTA9p M0Xu7PgFchHhSqrr+vbwe6vCj8zrrh+tpWMUnlotNZFd5dePNXuJEIRGCVS1rSUt mox5JZak1Xd9DPv/jl36XWWb064FLw== =xh8S -----END PGP SIGNATURE----- --Apple-Mail=_42E4E7FE-5951-412D-97BE-7A80B7D9365D-- From nobody Wed Oct 9 09:24: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 B07CA120145 for ; Wed, 9 Oct 2019 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 fMBgl9D-NxyJ for ; Wed, 9 Oct 2019 09:24:27 -0700 (PDT) Received: from smtp96.iad3a.emailsrvr.com (smtp96.iad3a.emailsrvr.com [173.203.187.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6509312085E for ; Wed, 9 Oct 2019 09:24:27 -0700 (PDT) X-Auth-ID: bgreene@senki.org Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 45774254E9; Wed, 9 Oct 2019 12:24:26 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [10.0.0.246] (c-73-15-67-108.hsd1.ca.comcast.net [73.15.67.108]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 09 Oct 2019 12:24:26 -0400 From: Barry Greene Message-Id: <7ABDABF3-2AE4-405D-9B14-407B88D33025@senki.org> Content-Type: multipart/signed; boundary="Apple-Mail=_CB9A841D-6C05-4918-99D4-EBABD29157FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 9 Oct 2019 09:24:24 -0700 In-Reply-To: Cc: Joe Abley , ADD Mailing list , David Lawrence To: Ted Lemon References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 16:24:32 -0000 --Apple-Mail=_CB9A841D-6C05-4918-99D4-EBABD29157FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2019, at 7:30 AM, Ted Lemon wrote: >=20 > I think this could still be noticed. You=E2=80=99d need intelligence = on the device noticing that there are surreptitious connections being = made. Device oriented security works on a limited set of devices. It is not on = my Nest, Cameras, other IoT devices in the home. --Apple-Mail=_CB9A841D-6C05-4918-99D4-EBABD29157FE 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----- iQEzBAEBCgAdFiEEdoGA/YBcwd1ud+j1VW6TcBa/RfMFAl2eCbgACgkQVW6TcBa/ RfM5xAf9HGklE/AZ0fwi4ozrQgi3ig5Fb/WWHFVUvDaVJDH4mdP1l1X9wwl6022l c0PPHjWcSGU8y+9zGH+A01NEd2A45FCZAwO76trSMzJJoAYyIJf3cIEZN/VOnIYU Ygtgz26tgyypgdL1om5XMTEOnKqKJwUVIyqXL03wV3prDsMvU2DVzoC0bAtVnKgX fxNYGXOhLzN5d0TTUm3H9GmXw0H6ZbtvFh9gPOB3BkX28KvcYbAzXNe6Gm/NEwoT g7sw1D+CYPEYb+m6Nd/aGpW/1enqx428/Qg62MTaYNWD192IXbZmutqOM+mJakIt KNuzHTeAywx5Gq3S2iYENzxnXroqSA== =9sl7 -----END PGP SIGNATURE----- --Apple-Mail=_CB9A841D-6C05-4918-99D4-EBABD29157FE-- From nobody Wed Oct 9 09:28: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 C98E4120170 for ; Wed, 9 Oct 2019 09:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k60jskr9k1um for ; Wed, 9 Oct 2019 09:28:03 -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 D9CA0120145 for ; Wed, 9 Oct 2019 09:28:02 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id c4so4231332qtn.10 for ; Wed, 09 Oct 2019 09:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pobb9XApE+SHqFNIllAOeAHOlDxR3JKjOUiDWLp7mQM=; b=mZ1vyXoNCOBPydZyOP1yNAMCUBFqd2+BhipYPw9ruOSaUM4muGPIyfiKEN1P2DWUAq PoEJEUxS15ZPr9zY1KP9fwKB7N91EXl0sjdC4m+lJDavYF7gemWehjiiB8UpTlSCXEyT SAa5hsVsVlfJVjhtPBfsoapbAp82mntEClZs5TOaeCD825EbFHeZ3C2Cw7Eda4Hidrfr CuPfbDBGRSkbh5h8+AfdR9nBuN2rrmZbvdzUB/h53xE8cWu8zrMxuOOI6NR9gvSamatS 8s0vIw07hDCsZX5+rsbUsxxeGSQiXZ5yuXKSanYUur2Bqqf0OSAv1GXmhJuF6+uyVmuh bq3A== 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=pobb9XApE+SHqFNIllAOeAHOlDxR3JKjOUiDWLp7mQM=; b=hPQWT14tBHHDg59sXdkcncPoytxdnHgLlIl5x7vL4sgmnuEPf1+u+Z0e+z5KgHXM8+ s+tNN5VRHASDd9ahU25v6iJyMSD2XhsrDtqRHmRnaSgzYB0QtsWIq9nkbueD290+yGmG BJsp9vdX/FP+05d2wEQRIBlKViYaGlYUq4HOlveGyInWjxcgIZaKw8X3H/5DSLalceDh rbTIksj1CCI7MIxyH9NZa10bumO9BJ9PprvwG+epDYUGMAYIz+fpjjI8DjgkkqObl6cY ADoh5/7L8RphfMlTUkv1cr4Tgn4JfWlVeDO9jn8setk+l8UOKjUFDtocBqbeXS2ebJeF RqLQ== X-Gm-Message-State: APjAAAVjxFgbWt0KMZa4YfolzoA+IWCbafycFFmp4VUntUyiJbIDv+o0 1lM/ZgNwHi5Z9Mc1kn4wAFWWPg== X-Google-Smtp-Source: APXvYqwkgzZMEW+Sg+0GB+sp3TgJhe9+WOL/BrhJzkJ8Ckfk0AY1GVxuUeJydb5XtRIeuODXOZb9IQ== X-Received: by 2002:a0c:fc10:: with SMTP id z16mr4726401qvo.2.1570638481790; Wed, 09 Oct 2019 09:28:01 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id n21sm1255652qka.83.2019.10.09.09.28.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 09:28:01 -0700 (PDT) From: Ted Lemon Message-Id: <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E299883C-926F-4176-9D76-E3278AA45A60" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Wed, 9 Oct 2019 12:27:59 -0400 In-Reply-To: <7ABDABF3-2AE4-405D-9B14-407B88D33025@senki.org> Cc: Joe Abley , ADD Mailing list , David Lawrence To: Barry Greene References: <7ABDABF3-2AE4-405D-9B14-407B88D33025@senki.org> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 16:28:05 -0000 --Apple-Mail=_E299883C-926F-4176-9D76-E3278AA45A60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 9, 2019, at 12:24 PM, Barry Greene wrote: > Device oriented security works on a limited set of devices. It is not = on my Nest, Cameras, other IoT devices in the home. You misunderstand my point. I mean that a security researcher with one = of these devices in their lab should be able to notice miscreants. = E.g., why is my Nest camera connecting to that server in East Agulfia? = Nest isn=E2=80=99t in East Agulfia. For constrained devices this = isn=E2=80=99t even a challenge. The problem with these devices is that = at present in most cases no such constraints are applied to them. Mud = does a pretty good job of solving this problem. --Apple-Mail=_E299883C-926F-4176-9D76-E3278AA45A60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 9, 2019, at 12:24 PM, Barry Greene <bgreene@senki.org> = wrote:
Device = oriented security works on a limited set of devices. It is not on my = Nest, Cameras, other IoT devices in the = home.

You = misunderstand my point.   I mean that a security researcher with = one of these devices in their lab should be able to notice miscreants. =   E.g., why is my Nest camera connecting to that server in East = Agulfia?   Nest isn=E2=80=99t in East Agulfia.   For = constrained devices this isn=E2=80=99t even a challenge.   The = problem with these devices is that at present in most cases no such = constraints are applied to them.  Mud does a pretty good job of = solving this problem.

= --Apple-Mail=_E299883C-926F-4176-9D76-E3278AA45A60-- From nobody Wed Oct 9 09:38: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 22DC412085B for ; Wed, 9 Oct 2019 09:38:20 -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_HELO_NONE=0.001, 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 agHEmL9S_IHO for ; Wed, 9 Oct 2019 09:38:18 -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 D265E120170 for ; Wed, 9 Oct 2019 09:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A134CBDCF; Wed, 9 Oct 2019 17:38:14 +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 UaNx5oEYPylf; Wed, 9 Oct 2019 17:38:14 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1960BBE2E; Wed, 9 Oct 2019 17:38:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1570639093; bh=NjEaQD8P9YRqYCr9r719v2xPgkLX3jN5g1PeXNPCfsU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ijm8t6zI0YtZdjNQ2GIsq46F2rWUQ713C2Vv1P1QpCLMbdyoIB1T1Che8tzc3SBII h1yUAi/ZtIqIpbjZ1unFYcTAmH3IJCcCTfFxwkwWDA/2kRBWbo2b22e5/CXaU+NwXw TqmEd37/pRKAPPtgEPUZrCOUztBKKIyU0f3iG6qg= To: Jari Arkko , Eric Rescorla Cc: Barry Leiba , ADD Mailing list References: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.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: <7e47cc37-b0ae-a0d5-1483-e8bcf6119ed0@cs.tcd.ie> Date: Wed, 9 Oct 2019 17:38:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JyIxew641HpYULVngZwI6AFMiQYdErgz" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 16:38:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7JyIxew641HpYULVngZwI6AFMiQYdErgz Content-Type: multipart/mixed; boundary="azgI9XKyrrw6bplwPijfyVGsDpUhjncZL"; protected-headers="v1" From: Stephen Farrell To: Jari Arkko , Eric Rescorla Cc: Barry Leiba , ADD Mailing list Message-ID: <7e47cc37-b0ae-a0d5-1483-e8bcf6119ed0@cs.tcd.ie> Subject: Re: [Add] Proposed charter and BoF request for IETF 106 References: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.net> In-Reply-To: <1EDDCFC4-02F7-4FE3-A99D-898E067EBF41@piuha.net> --azgI9XKyrrw6bplwPijfyVGsDpUhjncZL Content-Type: multipart/mixed; boundary="------------AB1A09AED9434ABB11671556" Content-Language: en-GB This is a multi-part message in MIME format. --------------AB1A09AED9434ABB11671556 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/10/2019 14:50, Jari Arkko wrote: > But I also think that we have to say something about privacy, > pervasive monitoring and centralisation issues. From my perspective > if we work on this topic at all, we=E2=80=99d be not doing our duty if = we > didn=E2=80=99t consider those aspects. +1 While I'd be pleasantly surprised if we could reach rough consensus on how to "fix" the privacy impacts of the centralisation that may accompany use of DoH in browsers, I do think we ought consider this as a challenge to tackle as best we can. For example, if we have protocol design choices to make, related to say discovery, then considering how those enable or encourage or discourage centralisation should be in scope questions to ask in the putative WG. Cheers, S. --------------AB1A09AED9434ABB11671556 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----- --------------AB1A09AED9434ABB11671556-- --azgI9XKyrrw6bplwPijfyVGsDpUhjncZL-- --7JyIxew641HpYULVngZwI6AFMiQYdErgz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2eDPQACgkQWrL68XsX K+phjw/8DHIb0s+pvvIybZlgE6RkV8ZIiXASQQii73g5iX1a5XqIowGTgOb2n87c ygJs9JgwMhG0Bz9SKbIN6MvZc17wlDNDq/t9xYOWqYbsZbDq8asr9i1AiI9Rt6uw ulAaLd7YeJdbthde8SEB+XnvxQsLQFJSfXCXdPXHa0Ufoz4aUi1qSBpprRc6NSiu 1u2hEZa/GOS5KylR4ki/czo0ZCRfyMXRp5O22sssXNeG/BzStx1+daztrSIQFfut FlA46IKeKFe8C7iDeYDYZ77kgfzYWxVT2cAOxWDNk539Pe8nHnXAVT9RmVw472Nl EZG1vilRU6NNIyKrTfV2AwXFqOtKwtK4H63fJwVpYKIkeH8E55leMfZoi5pmwzou RYR3xWsHUPPkJk2/TyhtgHlBJH+ndLoR7c/nyZilIOzx5p8AaoK8sxNH4y3t0ziY 8MUH5BYk0ihKWDvf2+32h8nKrQa27M2i5W5hvET/LiKyCDca3YZyj77Fp83Ihulh fTvye+wlzNbDl1px+OPYcNqCEgq0/rFTb0WPO/MSMnvI0OvX2f66RFXKy+tsYGcf 5cRYsh0zp4hBowx26J8dpmRxKmoE3ohWPwKWgvrx64aWiSqfs3h9cWgRSOGpreHU zaEsqa0R1gAPRreSwfCAGwB8YbXNEnL+BOH0E88tlVDt4ignkTU= =TFec -----END PGP SIGNATURE----- --7JyIxew641HpYULVngZwI6AFMiQYdErgz-- From nobody Wed Oct 9 09:41: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 F086C120170 for ; Wed, 9 Oct 2019 09:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 DZLq6k9fuF2N for ; Wed, 9 Oct 2019 09:41:31 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 55D1C120145 for ; Wed, 9 Oct 2019 09:41:31 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id y3so3183991ljj.6 for ; Wed, 09 Oct 2019 09:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=U+8wysIlXHS7dgJ0LLbkyiRsnZVDIiZcFXW7qaFGis8=; b=i/xLV6Kntdcui5G1pLhoUchabljP22pAf0+pqJi3krhqPSV+5PNDBXugzZ+7yrSaMX XobdroEGo4zemU+ogGiYrU0JlDUCY4+8gLedf2SQXuU8J5OqBUytJoDW1c+RON5rMwK0 AQkspu4ThFebZTFn8s6D0Ku6CaDHK28wmv03w= 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:references:in-reply-to:date :message-id:subject:to:cc; bh=U+8wysIlXHS7dgJ0LLbkyiRsnZVDIiZcFXW7qaFGis8=; b=S40M3rPZ7GAbSELHqpsspzWWDUT8HJDFnAD/C9R3mbS60bAE+B7UWMMPMKDo1L6hhg DYF/DJoXb5mp37/TLWUuo/ZLfr+O9CS6JEC07JhEd7TMCVA5jlbo1oKONpEN4I333PN6 j6D2KAcub4JEnycc1wYi+g/Uyasj1LoKKa4n8B2axsAQW7qxSRpXGOT42k171B5YYxO2 V+c+6O0/REf0786bCGvHT701AT+J2FH7oDhZE8eVjZIJYxQ8l5qnl93OMOOF+3dI3+ZF v+kaKmFuKu6q0QfhCVIeHTcgY7KvvVNVmsCRjW57B7JXjsgFD+C9nyf5oo61jnGD+xjO h8mg== X-Gm-Message-State: APjAAAUa7Zy4oaq8TwGVPCqXS4K2giU+k5gppFgyr6Pnnbhuz61k/8gl ish33Qb5T3JxhtV4Sf+f+1PGErbekVtRdGG4pdLvMENiMKAGqA== X-Google-Smtp-Source: APXvYqwoMjn6XXkLkPkDgYvxoU8ytWXeOf6wrAU4eNQOrmPTF8SnAHNZW6tKyHjJekdYOa7XNvswMA23pBAfnt+mzug= X-Received: by 2002:a2e:89c4:: with SMTP id c4mr2874159ljk.171.1570639289429; Wed, 09 Oct 2019 09:41:29 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Wed, 9 Oct 2019 09:41:28 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> In-Reply-To: <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> Date: Wed, 9 Oct 2019 09:41:28 -0700 Message-ID: To: Ted Lemon Cc: Barry Greene , ADD Mailing list , David Lawrence Content-Type: multipart/alternative; boundary="000000000000eac35d05947cf4e7" Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 16:41:34 -0000 --000000000000eac35d05947cf4e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Oct 9, 2019, at 12:27, Ted Lemon wrote: =EF=BB=BFOn Oct 9, 2019, at 12:24 PM, Barry Greene wrot= e: Device oriented security works on a limited set of devices. It is not on my Nest, Cameras, other IoT devices in the home. You misunderstand my point. I mean that a security researcher with one of these devices in their lab should be able to notice miscreants. E.g., why is my Nest camera connecting to that server in East Agulfia? Nest isn=E2= =80=99t in East Agulfia. Nest is google. I assume Google is everywhere. My example was CloudFlare. CloudFlare IIS potentially the connection point for everybody, and they were turning up new nodes at a high frequency even before their IPO. I assume that CloudFlare is everywhere. You get my point, I'm sure. I agree this is a bit of a tangent. Joe --000000000000eac35d05947cf4e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Oct 9, 2019, at 12:= 27, Ted Lemon <mellon@fugue.com&= gt; wrote:

=EF=BB=BFOn Oct 9, 2019, at 12:24 PM, Barry Greene <bgreene@senki.org> wrote:
Device oriented security works on = a limited set of devices. It is not on my Nest, Cameras, other IoT devices = in the home.

= You misunderstand my point. =C2=A0 I mean that a security researcher with o= ne of these devices in their lab should be able to notice miscreants. =C2= =A0 E.g., why is my Nest camera connecting to that server in East Agulfia? = =C2=A0 Nest isn=E2=80=99t in East Agulfia.
Nest is google. I assume Google is everywhere.=C2=A0

My example was CloudFlare. CloudFlare IIS potentially the c= onnection point for everybody, and they were turning up new nodes at a high= frequency even before their IPO. I assume that CloudFlare is everywhere.= =C2=A0

You get my point, I'm sure. I agree thi= s is a bit of a tangent.


Joe
<= /body> --000000000000eac35d05947cf4e7-- From nobody Wed Oct 9 09:48:05 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 2414B120096 for ; Wed, 9 Oct 2019 09:47:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 NMJYucnMrlaA for ; Wed, 9 Oct 2019 09:47:56 -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 60F6B12089B for ; Wed, 9 Oct 2019 09:47:56 -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 8620E6A284; Wed, 9 Oct 2019 18:47:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570639674; bh=CU/2F4qf1r+EbLtnywTCJ8eKb/2RXuydKo2bNPDUHCw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=VGNTXI8KnsxJ5FU74FgHSSia3D5vH7LvGKVjRXrKgzqBnwzKO0cKJ3FIFoCOsAHAT zP7MCVwN+BKtdF3dwl/vEonrSLSj2G/pwkxVzGyRy6omizUi/JowVbsurxi780hPah PBkgx9cgcqR2mBH5bfj7Uy4G0Z4+cnwmNEU9oDTrEIHWDcVBAy3RXfS/mbJiOX1ck/ FTuRwpXfiGSaCp5fjU0lYrbNyoNNS5DamAXZQfhPE4mO+aAMBXgvhDtXk3I8pLIk3P EqhkpZyosSzYKkzPrE9i3S/FUL28iLlM8j2nCiR/ckoyMOj/HTDPNhW/uVmYEIjMVD S/c+Occ4MrxZA== 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 7957B3C04BB; Wed, 9 Oct 2019 18:47:54 +0200 (CEST) Date: Wed, 9 Oct 2019 18:47:54 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Richard Barnes , add@ietf.org Message-ID: <1286342342.28404.1570639674402@appsuite-gw2.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 16:47:58 -0000

Il 9 ottobre 2019 16:21 Richard Barnes <rlb@ipv.sx> ha scritto:


I think EKR is on the right track here. 

There is a bright line here between technology and deployment policy.  The former we have some hope of progressing on, and there are meaty questions around how applications can discover local network capabilities and preferences in a way that is not open to abuse like the mechanisms we have today.  On questions of the latter form, the entire history of this list, and the meeting that preceded it demonstrate, that there is very little hope of consensus. 

The charter right now has some of both.  If this charter is to go forward, it should be refactored to focus on engineering questions, and avoid policy questions.  In particular, the BCP item needs to be struck.
I see the reasons behind this line of thought, but honestly, seen from my viewpoint, it looks like the IETF is playing hide and seek on the non-technical issues. It starts a deep change in a basic technology for the entire Internet, with at least one AD stating in public things like "we're going to save dissidents and journalists with this new technology", then when the real world problems of that approach come up, the IETF backs away and says "sorry, we only deal with the engineering questions". So yes, you can strike any policy and deployment model discussion from the charter, but then you should also strike RFC 7258 - what is it, if not a policy statement?

(Before someone jumps at my throat, I'll stress that I'm not actually arguing against RFC 7258, I'm just noting that it's too late to claim that the IETF does not do policy, at least in this area.)

This said, I do not have a firm opinion yet on this; I see that having the deployment model in the charter might derail technical developments that could instead get to consensus. So it might still be a wise decision for the IETF to say "we have realized that there are complex policy and juridical issues stemming from this and we are not well equipped to deal with them, so we declare them out of scope".

The unavoidable consequence, however, would be that the policy discussion moves somewhere else, possibly somewhere in the I* galaxy, for the global, non-binding and opinion-making debates, and into national Parliaments for any hard law if required. So the IETF must then be prepared to accept that other parts of the ecosystem might have other views on how the DNS should work and which use cases it should support, and cooperate with their conclusions.

And to be honest, even if the IETF decided to tackle the policy issues and managed to come up with a best practice, it could easily be that other policymaking entities got to different conclusions and asked the engineers to align.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Wed Oct 9 09:56: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 2F8D5120168 for ; Wed, 9 Oct 2019 09:56:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 z2rAMQKGVWzb for ; Wed, 9 Oct 2019 09:56:33 -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 0212A120026 for ; Wed, 9 Oct 2019 09:56:32 -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 561666A284; Wed, 9 Oct 2019 18:56:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570640191; bh=ruM9qALZEth8742+IIXZjSj9LOemdyHaw25mDLROtC4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=lR1iWgKRdid2xqCLRrzRxAMB/EXux5lIkyqT+BR03GTy1GwidkPzRnvR3HK4IFUF8 ROwuVX666L2th9G8VSuaAWp0YQwPrkFw6I2D4//uzOassV/T52hc9+TiqdkQzXa4ao ZG+Y0e1GgRsrC5bHyqIS8AC+CAY7cYAwRh+/njCl13mLt8NfGu7gd9DhKmh8TeC8bO 7tGv/SHgAMs0sbz56pecx+jKa3t5qAx1SPYrcCV+XCH9x8vIHF1wtm7JNL1+7SkrA0 yU9scSGkSWPDxvdkCi5aRsRfe28zqOfFliSr2okK9llfW6PykcjxvFBqeNPn+PqHu8 wmZBlB66LUYdg== 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 49B1A3C029C; Wed, 9 Oct 2019 18:56:31 +0200 (CEST) Date: Wed, 9 Oct 2019 18:56:31 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Eric Rescorla Cc: ADD Mailing list Message-ID: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 16:56:35 -0000

Il 9 ottobre 2019 13:58 Eric Rescorla <ekr@rtfm.com> ha scritto:

> Achieving these
> objectives while providing confidentiality and tamper-resistance will
> generally require that network operators shift to one of the available
> encrypted transports for their resolvers and that clients include
> configuration options to select them.

This entirely misses the point, which isn't just to do a lot of encryption
but to provide security for the user. Just having network operators
transition to secure transports while continuing their current practices
does not address the issue.
Sorry, now it is my turn to dot the i's: certainly *some* network operators in your country adopt *some* current practices that Mozilla do not like, and neither do I. But you cannot generalize this like that, and then use it as a reason not to enable the other network operators to shift to encrypted transport while continuing their practices exactly like they are, for the full satisfaction of their existing users.

And by the way, making judgements on whether the commercial practices of a given company are acceptable really looks like a policy issue.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Wed Oct 9 10:05: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 8C7F21208E3 for ; Wed, 9 Oct 2019 10:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBLUOmYmenw3 for ; Wed, 9 Oct 2019 10:05:41 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450: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 CE9A51208E1 for ; Wed, 9 Oct 2019 10:05:40 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id w6so2234008lfl.2 for ; Wed, 09 Oct 2019 10:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=plGZQMSeGhlM++an8Vz2kgUpcUY7qgiFfpg5QVtkSoA=; b=gKQdPpht1epMYPbUcpopkLvVVth5MqY+3QMGZXIKSM7yxJ3rJ1ts7M/onACAphdMdj OWL/R9L6i/jTnMTvH2Moaax/ygxGhO9IKMkiUcqasKDnODyaH2CmAffB3/zqA7pz1hzu UWMochklI9K960k8qJonLPjfN9Hjbm4fL/CVM6jVa6ZRCQuwMdURE5vWhtlnLG7X1WDl bq6J6+dgSJHUrb6DzgPRSzDQ92gH4+ziPqf9TbkZ2G+q150IjDlFav9aBYzmAYeY0HcX 7YdHyseyp8j1lTockgjzTHSoY+IZ0s8IKYLjBuK6w9t5tBMCqZcjLQz6c7x2zImYOK7z 9MYw== 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=plGZQMSeGhlM++an8Vz2kgUpcUY7qgiFfpg5QVtkSoA=; b=UNA/+tsZBrBiEk92Q5+uYjjRrMlrHfYL6Ze9b/ZGQvPawNubeOpvpw8K1svfc9sh1k i/SawRUDTZ5SIZOFwvJXTJKJM9Nnra1bpg9iDsn102cEv6DaMIMcSsHXcDjr+7gJhFeF DHS/pMqpvCBiMPtDm2ism1mRv6yeatonB5AJLyIwUS1+b07PwPpwasIe4m0fciuc6w4f jMvRvK2WwWLxqDhC0Go3qH9o2LmpszQ4O8kFRJs95vbriDALJtv8sba17P/2BmZ47Te1 l29bORDPHyivqNQ6fkbvCEIGICU5nAJrJRxERr0Kniny2xwIl1WDNk6mtAZyn7FfdvTT YFqg== X-Gm-Message-State: APjAAAXijbDPXNEkIXMZwAh3oJnFbU1nKAWLo2od45W/HeBkPF8nw5Ex i9ZmqdVNmAV2fMAeFX0ItTKIB/tVEQ8dliUXatAWFFP8 X-Google-Smtp-Source: APXvYqzwqBPk3LDSnQCqz6UgrukRGZoBXfr5Eo+VeCH6OZHIFznV062vRNIihpkuM7Q+G585SZFgPsQoMlQe1rR7g4Y= X-Received: by 2002:a19:7404:: with SMTP id v4mr2713251lfe.129.1570640738846; Wed, 09 Oct 2019 10:05:38 -0700 (PDT) MIME-Version: 1.0 References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> From: Eric Rescorla Date: Wed, 9 Oct 2019 10:05:01 -0700 Message-ID: To: Vittorio Bertola Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004f237705947d4bb4" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 17:05:42 -0000 --0000000000004f237705947d4bb4 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 9:56 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 9 ottobre 2019 13:58 Eric Rescorla ha scritto: > > > Achieving these > > objectives while providing confidentiality and tamper-resistance will > > generally require that network operators shift to one of the available > > encrypted transports for their resolvers and that clients include > > configuration options to select them. > > This entirely misses the point, which isn't just to do a lot of encryption > but to provide security for the user. Just having network operators > transition to secure transports while continuing their current practices > does not address the issue. > > Sorry, now it is my turn to dot the i's: certainly *some* network > operators in your country adopt *some* current practices that Mozilla do > not like, and neither do I. But you cannot generalize this like that, and > then use it as a reason not to enable the other network operators to shift > to encrypted transport while continuing their practices exactly like they > are, for the full satisfaction of their existing users. > > And by the way, making judgements on whether the commercial practices of a > given company are acceptable really looks like a policy issue. > You're misunderstanding me. I'm not saying that we should not enable network operators to shift to encrypted transport. As I said in the section of my message that you cut, I'm more than happy to have the IETF standardize a mechanism for the network to tell endpoints that it supports encrypted transport. I'm merely observing that this does not address the issue that Mozilla is trying to address with our DoH/TRR deployment. -Ekr > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --0000000000004f237705947d4bb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 9:56 AM Vittor= io Bertola <vittori= o.bertola@open-xchange.com> wrote:
=20 =20 =20

Il 9 ottobre 2019 13:58 Eric Rescorla <ekr@rtfm.com> ha scritto:

> Achieving these
> objectives while providing confidentiality and tamper-resistan= ce will
> generally require that network operators shift to one of the a= vailable
> encrypted transports for their resolvers and that clients incl= ude
> configuration options to select them.

This entirely misses the point, which isn't just to do a lot of= encryption
but to provide security for the user. Just having network operators
transition to secure transports while continuing their current prac= tices
does not address the issue.
Sorry, now it is my turn to dot the i's: certainly *some* network op= erators in your country adopt *some* current practices that Mozilla do not = like, and neither do I. But you cannot generalize this like that, and then = use it as a reason not to enable the other network operators to shift to en= crypted transport while continuing their practices exactly like they are, f= or the full satisfaction of their existing users.

And by the way, making judgements on whether the commercial practices of= a given company are acceptable really looks like a policy issue.

You're misunderstan= ding me. I'm not saying that we should not enable network operators to = shift to encrypted transport. As I said in the section of my message that y= ou cut, I'm more than happy to have the IETF standardize a mechanism fo= r the network to tell endpoints that it supports encrypted transport. I'= ;m merely observing that this does not address the issue that Mozilla is tr= ying to address with our DoH/TRR deployment.

-= Ekr

<= div>

--=20 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--0000000000004f237705947d4bb4-- From nobody Wed Oct 9 10:14: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 A1A24120968 for ; Wed, 9 Oct 2019 10:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 l8Q9kFCuxRIN for ; Wed, 9 Oct 2019 10:14:36 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C22120954 for ; Wed, 9 Oct 2019 10:14:36 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id c10so2369544otd.9 for ; Wed, 09 Oct 2019 10:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BZCVQ9KeMjEudI8T0gjJN5VuDSPK7ZUWGf3LfqJ1KQA=; b=MS1xqqDpIm7ezvwgMUBAREMapqVAm82GPG+SNzTC/+uSobxU46B8acAx5gaL6f0f7t 2sbZmNLoeZfcJxlNCPjG+EYV5eQUxITCJyx2D84APtn3Ik5j/0N0krwf+ZziZIZt9vP6 VcN52rblJCghr1/L1vyzQMdOT3aixRCq/GLDUolBwbu+Iu5PmJP2F4SatobFE0aBgUap Ge632dS5xlzTzH+XnQ4tmob3EDEGPUKft8naHpRuIOwu19Bs+8k5hUD3nx/55h3SsCoK 4o6NHEu8lfhZeSQqZx8Ro6nqML9bc9Jc6ZtHPg1Bg/jz96aWI6vfednZMopb3bKccLfV ACAA== 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=BZCVQ9KeMjEudI8T0gjJN5VuDSPK7ZUWGf3LfqJ1KQA=; b=MgYv4vKe/NU/Zyq7eLiLHQG7LkorzAi/GPb5UPAbJQrCq7cmScvEkR5di+vOqMQ6Dr AKmF+Wpss8hfwVAJN80iVQXeC64RckuuRKYJjiXMRqggkhioaidrinDNYFv6BhHAna73 k4KpAImqDX0wQRPiin0DueKAsSo8a7WFsLJpDRe+/RrIvGsMKTabURvKanf+K0bik5mi G2SG2Qg6yynb/0hiyQfj8MBRPNPv/u5Mbf+Qm63mPHkF7v9CmlR7b18WoLOCcSm/XwQN wxYuIUZOClhSQ9Yux2WRO12ZmB6tWvJ45Yli53qo2xkKuxuP3HgdcUNIqZGIe5Ij9uS1 uAfg== X-Gm-Message-State: APjAAAWPkO9O7s/rpepYOAuVuzz9rc7QIzDxSWd18ErPKNFrjgIK9+Hf f/MEkOWyAmhoJ0HQABG/0dyCHbSbZHa9HqPisx8cg3Mp X-Google-Smtp-Source: APXvYqx6IgHwFTo7TClnTUL3Da09fauaggDpr95l3IYzqIav9P72YI0Xdp38XIz2xgOYccVQuCl6MDHDdNpueUbFPCQ= X-Received: by 2002:a9d:550a:: with SMTP id l10mr3879659oth.93.1570641275126; Wed, 09 Oct 2019 10:14:35 -0700 (PDT) MIME-Version: 1.0 References: <1286342342.28404.1570639674402@appsuite-gw2.open-xchange.com> In-Reply-To: <1286342342.28404.1570639674402@appsuite-gw2.open-xchange.com> From: Richard Barnes Date: Wed, 9 Oct 2019 13:14:22 -0400 Message-ID: To: Vittorio Bertola Cc: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000461c5105947d6b3b" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 17:14:43 -0000 --000000000000461c5105947d6b3b Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 12:47 PM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 9 ottobre 2019 16:21 Richard Barnes ha scritto: > > > I think EKR is on the right track here. > > There is a bright line here between technology and deployment policy. The > former we have some hope of progressing on, and there are meaty questions > around how applications can discover local network capabilities and > preferences in a way that is not open to abuse like the mechanisms we have > today. On questions of the latter form, the entire history of this list, > and the meeting that preceded it demonstrate, that there is very little > hope of consensus. > > The charter right now has some of both. If this charter is to go forward, > it should be refactored to focus on engineering questions, and avoid policy > questions. In particular, the BCP item needs to be struck. > > I see the reasons behind this line of thought, but honestly, seen from my > viewpoint, it looks like the IETF is playing hide and seek on the > non-technical issues. It starts a deep change in a basic technology for the > entire Internet, with at least one AD stating in public things like "we're > going to save dissidents and journalists with this new technology", then > when the real world problems of that approach come up, the IETF backs away > and says "sorry, we only deal with the engineering questions". So yes, you > can strike any policy and deployment model discussion from the charter, but > then you should also strike RFC 7258 - what is it, if not a policy > statement? > It is indeed a policy statement -- and one around which there was strong consensus at the time it was published. (I expect there still is.) It's not that I think the IETF can't make policy statements of this character, it's that there's no indication that there's any policy statement in this domain around which there is consensus to be had. --Richard > > (Before someone jumps at my throat, I'll stress that I'm not actually > arguing against RFC 7258, I'm just noting that it's too late to claim that > the IETF does not do policy, at least in this area.) > > This said, I do not have a firm opinion yet on this; I see that having the > deployment model in the charter might derail technical developments that > could instead get to consensus. So it might still be a wise decision for > the IETF to say "we have realized that there are complex policy and > juridical issues stemming from this and we are not well equipped to deal > with them, so we declare them out of scope". > > The unavoidable consequence, however, would be that the policy discussion > moves somewhere else, possibly somewhere in the I* galaxy, for the global, > non-binding and opinion-making debates, and into national Parliaments for > any hard law if required. So the IETF must then be prepared to accept that > other parts of the ecosystem might have other views on how the DNS should > work and which use cases it should support, and cooperate with their > conclusions. > > And to be honest, even if the IETF decided to tackle the policy issues and > managed to come up with a best practice, it could easily be that other > policymaking entities got to different conclusions and asked the engineers > to align. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --000000000000461c5105947d6b3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 12:47 PM Vitto= rio Bertola <vittor= io.bertola@open-xchange.com> wrote:
=20 =20 =20

Il 9 ottobre 2019 16:21 Richard Barnes <rlb@ipv.sx> ha scritto:


I think EKR is on the right track here.=C2=A0=20

There is a bright line here between technology and deployment policy.= =C2=A0 The former we have some hope of progressing on, and there are meaty = questions around how applications can discover local network capabilities a= nd preferences in a way that is not open to abuse like the mechanisms we ha= ve today.=C2=A0 On questions of the latter form, the entire history of this= list, and the meeting that preceded it demonstrate, that there is very lit= tle hope of consensus.=C2=A0=20

The charter right now has some of both.=C2=A0 If this charter is to g= o forward, it should be refactored to focus on engineering questions, and a= void policy questions.=C2=A0 In particular, the BCP item needs to be struck= .
I see the reasons behind this line of thought, but honestly, seen from m= y viewpoint, it looks like the IETF is playing hide and seek on the non-tec= hnical issues. It starts a deep change in a basic technology for the entire= Internet, with at least one AD stating in public things like "we'= re going to save dissidents and journalists with this new technology",= then when the real world problems of that approach come up, the IETF backs= away and says "sorry, we only deal with the engineering questions&quo= t;. So yes, you can strike any policy and deployment model discussion from = the charter, but then you should also strike RFC 7258 - what is it, if not = a policy statement?=20

It is indeed a policy s= tatement -- and one around which there was strong consensus at the time it = was published.=C2=A0 (I expect there still is.)=C2=A0 It's not that I t= hink the IETF can't make policy statements of this character, it's = that there's no indication that there's any policy statement in thi= s domain around which there is consensus to be had.

--Richard

=C2=A0

(Before someone jumps at my throat, I'll stress that I'm not act= ually arguing against RFC 7258, I'm just noting that it's too late = to claim that the IETF does not do policy, at least in this area.)

This said, I do not have a firm opinion yet on this; I see that having t= he deployment model in the charter might derail technical developments that= could instead get to consensus. So it might still be a wise decision for t= he IETF to say "we have realized that there are complex policy and jur= idical issues stemming from this and we are not well equipped to deal with = them, so we declare them out of scope".

The unavoidable consequence, however, would be that the policy discussio= n moves somewhere else, possibly somewhere in the I* galaxy, for the global= , non-binding and opinion-making debates, and into national Parliaments for= any hard law if required. So the IETF must then be prepared to accept that= other parts of the ecosystem might have other views on how the DNS should = work and which use cases it should support, and cooperate with their conclu= sions.=20

And to be honest, even if the IETF decided to tackle the policy issues a= nd managed to come up with a best practice, it could easily be that other p= olicymaking entities got to different conclusions and asked the engineers t= o align.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--000000000000461c5105947d6b3b-- From nobody Wed Oct 9 10:15: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 CE30A12093C for ; Wed, 9 Oct 2019 10:15:26 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 NUGz0ZtK3fdx for ; Wed, 9 Oct 2019 10:15:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 3A9491208D6 for ; Wed, 9 Oct 2019 10:15:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pLSq0d4qzFb4 for ; Wed, 9 Oct 2019 19:15:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570641323; bh=SJvnZ55rTbu4c34WINKM4xSb7KR/O0UPqd2rHkMxPeM=; h=Date:From:To:Subject:In-Reply-To:References; b=omdBft4UCsVfByCsxJX0cFnpP8lWisp3D9hqM3invf/FIlQV7pNf2+SBsWsuxDOm6 q/ODZr+lvzalEi+xJ78DSUmwAropQ7mEin9m+aUf+qNODcx/nIa2FdhdxkVCwnWroA cohVcM6g5emYzrz++Q0+qdIV4dyp0V62FB+5TEnI= 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 qNtjRPmVN5JH for ; Wed, 9 Oct 2019 19:15:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 9 Oct 2019 19:15:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 12089607F1DF; Wed, 9 Oct 2019 13:15:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 10A1465E60 for ; Wed, 9 Oct 2019 13:15:21 -0400 (EDT) Date: Wed, 9 Oct 2019 13:15:21 -0400 (EDT) From: Paul Wouters To: add@ietf.org In-Reply-To: Message-ID: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 17:15:27 -0000 On Wed, 9 Oct 2019, Eric Rescorla wrote: > You're misunderstanding me. I'm not saying that we should not enable network operators to shift to encrypted transport. > As I said in the section of my message that you cut, I'm more than happy to have the IETF standardize a mechanism for > the network to tell endpoints that it supports encrypted transport. I'm merely observing that this does not address the > issue that Mozilla is trying to address with our DoH/TRR deployment. And it seems doing this at the DHCP / Captive Portal level is enough. I don't see the need for a WG to be spun up for this. Paul From nobody Wed Oct 9 10:33: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 9A74D1209DF for ; Wed, 9 Oct 2019 10:33:47 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 zezQ9Un0CRKm for ; Wed, 9 Oct 2019 10:33:46 -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 318F71209C7 for ; Wed, 9 Oct 2019 10:33:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pLsz5ZgYzFb9; Wed, 9 Oct 2019 19:33:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570642423; bh=dnx3qed2A9dmIyG5ES2OQvZ1LccJwa7a6AJpXeHI17s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=awp54VD684jZ0vd0oLnKPiIJkag8DGpRJbHb5Lrfr+1nU/ZBCqBpkcACVGCn2AvRd YIa2exIHwTZo12AXY5OeMZHlErEsYsDTVwDL6PhEFSb8XQUrqHAaOqqzKLVvU1lrQH s43184nOG6DL+HGBCO4wJiGWG+NG8IG6psP15vd4= 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 Ot-P21xaLiCQ; Wed, 9 Oct 2019 19:33:42 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 9 Oct 2019 19:33:42 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A5413607F1DF; Wed, 9 Oct 2019 13:33:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A163965E60; Wed, 9 Oct 2019 13:33:41 -0400 (EDT) Date: Wed, 9 Oct 2019 13:33:41 -0400 (EDT) From: Paul Wouters To: Barry Leiba cc: Rob Sayre , add@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 17:33:48 -0000 On Wed, 9 Oct 2019, Barry Leiba wrote: > So if it helps, consider "the IESG" as the charter proposal writers > and "5 or 6 ADs" as the BoF proponents. This is really weird by the way. The IESG proposing a BoF/WG which the IESG reviews to accept or not. It would be even weirder if the WG chairs selected will be IESG members or ADs. Paul From nobody Wed Oct 9 11:04: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 8621A120AA1 for ; Wed, 9 Oct 2019 11:04:31 -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_HELO_NONE=0.001, 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 3RINV2oxu82D for ; Wed, 9 Oct 2019 11:04:29 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 7761E120AA0 for ; Wed, 9 Oct 2019 11:04:29 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id n26so7055919ioj.8 for ; Wed, 09 Oct 2019 11:04:29 -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=U3l7K3atR4ozVeAb1g0mrMYJzpCAZcnVLSm53QYSPbY=; b=owGtv1ApxCOZcYVvJiQm4SEoTmcp4taVEPgpINftKPuYr/C9lVNTU2km7okBe9jWBQ Fxyja/VLdxl5twW1nXMZUKCmLh95jidBdHtj0adud6v+gHQoplcU+CHE+8nVrl/nQZBb TH3RmXkW80zw09r3JmsKjvzIlnMl4LTwRJOzDVmslkE+oRd333LBCLUjinAElI7z7wZC GdgRe/iTToxSHtBFL94LAFSDKQKNdULiyyoGnM3rwf3RpYR6OZUMdqGWjB/rhlkYWuJq x/Rn7WFZ/9Kg5HRbEFko08xW5K626UYr7VPWAOKBv3XyxAq8ZMq7wBgzIk98HSGhPg7p h2KQ== 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=U3l7K3atR4ozVeAb1g0mrMYJzpCAZcnVLSm53QYSPbY=; b=au+DkFmcf3t6AAN4xH95zPr36iOz85kJInYJvKKatZg3b+wpaUkqlHSy1XPfwTypug lYojDqBzzH08eD7FIh7TnHnk5XW7eBJM2xuKAfxy0sbEUYZxti5Yff37NzCdIDiNloxP GgoEbpeW+sKrJt813Sf3fOqmhLmkPkQuENFWlofbHSH12w4wycuTMBTGoivj/TAI0yxv SKjMjFnWgfWqbc5J84zWukIUUX6FgZmE6LL8cbQ1yAnIYmRbodP0gK9QucPiK8FjbBNP Grn8m+b8ZVhEQ5KhHBoNJbTfkhBMlZiQ5v3bmK/E61V4dQNt6kcN0vTX13ecOrb8bsVD kxnw== X-Gm-Message-State: APjAAAWk7Sk0cW0tzX8gTre+74pQgD9X+BUh6hbHs+tmiQ2slxAIWCfi +rP+JaWOlQ0KPYLOd5hnDIsOhoMXRjUll0rMhaUg3/L0 X-Google-Smtp-Source: APXvYqzwn03YfLGId1/AMPc8EKKz8YFNowoQFcC493EuaYEUha/AMWkwgsNE8xX0gaNvYsP/on3ulSqTHqaGrTmcbwg= X-Received: by 2002:a02:c919:: with SMTP id t25mr4577297jao.77.1570644268493; Wed, 09 Oct 2019 11:04:28 -0700 (PDT) MIME-Version: 1.0 References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: From: tirumal reddy Date: Wed, 9 Oct 2019 19:04:15 +0100 Message-ID: To: Paul Wouters Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b1322f05947e1d70" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 18:04:32 -0000 --000000000000b1322f05947e1d70 Content-Type: text/plain; charset="UTF-8" On Wed, 9 Oct 2019 at 18:15, Paul Wouters wrote: > On Wed, 9 Oct 2019, Eric Rescorla wrote: > > > You're misunderstanding me. I'm not saying that we should not enable > network operators to shift to encrypted transport. > > As I said in the section of my message that you cut, I'm more than happy > to have the IETF standardize a mechanism for > > the network to tell endpoints that it supports encrypted transport. I'm > merely observing that this does not address the > > issue that Mozilla is trying to address with our DoH/TRR deployment. > > And it seems doing this at the DHCP / Captive Portal level is enough. I > don't see the need for a WG to be spun up for this. > DHCP is not a secure way to discover the local DoT/DoH server. -Tiru > > Paul > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000b1322f05947e1d70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 9 Oct 2019 at 18:15, Paul Wouters= <paul@nohats.ca> wrote:
On Wed, 9 Oct 2019, Eric Rescorla wrote:

> You're misunderstanding me. I'm not saying that we should not = enable network operators to shift to encrypted transport.
> As I said in the section of my message that you cut, I'm more than= happy to have the IETF standardize a mechanism for
> the network to tell endpoints that it supports encrypted transport. I&= #39;m merely observing that this does not address the
> issue that Mozilla is trying to address with our DoH/TRR deployment.
And it seems doing this at the DHCP / Captive Portal level is enough. I
don't see the need for a WG to be spun up for this.

DHCP is not a secure way to discover the local DoT/DoH ser= ver.

-Tiru
=C2=A0

Paul

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000b1322f05947e1d70-- From nobody Wed Oct 9 11:32: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 02990120B0F for ; Wed, 9 Oct 2019 11:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGOnSO3znDB6 for ; Wed, 9 Oct 2019 11:32:41 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 713E5120B06 for ; Wed, 9 Oct 2019 11:32:41 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id l21so3533837lje.4 for ; Wed, 09 Oct 2019 11:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MaJ8DNnUEr4yzEWu6I5xXwAq/mu9M4mXxR+Q8VfZegE=; b=COnVvQC+TBzzWFl3ssFtpDrGzp3OCuuHkwKZ7LjZBH+vrFqSw7eS+DKIhn7DLPz5FK 8lRV0T4Ph8OvIS4jM1qlemjK+4iw+cOMzLgzyRZHtHNE/k4PnoB7o06IW8L7vH8km0ag PHV29pPQYXfsnOmA2dxScQCKsaLeR+N3qiSg493/wl0Xn8masKax7usqhq10ybrZVklZ cijEFxzFbRPwQKgZCCrNnqEI2/a3b6E+C54FwkwSz2C9fexi2+5b+EtDeWX0T7+NkoSL yvtDJDcpNoJok5UKh1dZtCIP5KRosgHW7wc/J+KBx+cNmrYS5tUzlUoiYMCueVOhGrb6 gErg== 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=MaJ8DNnUEr4yzEWu6I5xXwAq/mu9M4mXxR+Q8VfZegE=; b=HugpuFF3159vfsKdagJ9rasGuTlfBXmnM08c5PjRR0jSuGPhuIT6B1s+DiQqP7u853 2Ne+xeVedKI3ttHPM7UagHLoADuhXmRx68OPEpnws1PUhEeGcVAMFCNtxCagFshkT9u9 N3/rE/rb8LNAvra1uTdTyZa8IXDycR5kBCFxvwbcqEyvzckgnlTsyEp2v4WJtLmJAhqj 0LI6hj04c1XVqW+irYyCJKkRQXBeANJvUt3WpRC+t1k1RryyLZaWP3H98ntoNp04L8th hy8pJ/+clC66VWr8o/mVIC3cplIEwiGCkzHl1T2Eitu/6TwCzKyVRg8mWWxQ/sOfV+0m 4TOg== X-Gm-Message-State: APjAAAUmERqBFWEXXc8OFTu/lkZwOBPEMJfePt4Nykd0srbHJ68t9zOX GerBGiFb/BQK60DZ/bm4pXoEKkaITk9qbOKFRXS8sA== X-Google-Smtp-Source: APXvYqyTHt+V0czW7XpHTri8jp98OUjlfcYdD/Y0cgR3Vc/9CCKuWJwYqY3dZd9Ksuc20cM55OzAVsWEdd/OGBlWMd4= X-Received: by 2002:a05:651c:237:: with SMTP id z23mr3277529ljn.93.1570645959498; Wed, 09 Oct 2019 11:32:39 -0700 (PDT) MIME-Version: 1.0 References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 11:32:02 -0700 Message-ID: To: tirumal reddy Cc: Paul Wouters , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007bf02f05947e82ac" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 18:32:44 -0000 --0000000000007bf02f05947e82ac Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 11:04 AM tirumal reddy wrote: > On Wed, 9 Oct 2019 at 18:15, Paul Wouters wrote: > >> On Wed, 9 Oct 2019, Eric Rescorla wrote: >> >> > You're misunderstanding me. I'm not saying that we should not enable >> network operators to shift to encrypted transport. >> > As I said in the section of my message that you cut, I'm more than >> happy to have the IETF standardize a mechanism for >> > the network to tell endpoints that it supports encrypted transport. I'm >> merely observing that this does not address the >> > issue that Mozilla is trying to address with our DoH/TRR deployment. >> >> And it seems doing this at the DHCP / Captive Portal level is enough. I >> don't see the need for a WG to be spun up for this. >> > > DHCP is not a secure way to discover the local DoT/DoH server. > It would probably useful to start by defining what "secure" means in this context. For instance, I am in an airport and I see the name of the WiFi AP printed on the wall an join a network with that SSID. How would you define securely learning the DoH server? -Ekr > -Tiru > > >> >> Paul >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000007bf02f05947e82ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 11:04 AM tirum= al reddy <kondtir@gmail.com>= wrote:
On Wed, 9 Oct 2019 at 18:15, Paul Wouters <paul@nohats.ca> wro= te:
On Wed, 9 Oct 2019, Eric Rescorla wrote:

> You're misunderstanding me. I'm not saying that we should not = enable network operators to shift to encrypted transport.
> As I said in the section of my message that you cut, I'm more than= happy to have the IETF standardize a mechanism for
> the network to tell endpoints that it supports encrypted transport. I&= #39;m merely observing that this does not address the
> issue that Mozilla is trying to address with our DoH/TRR deployment.
And it seems doing this at the DHCP / Captive Portal level is enough. I
don't see the need for a WG to be spun up for this.

DHCP is not a secure way to discover the local DoT/DoH ser= ver.

It would probably us= eful to start by defining what "secure" means in this context. Fo= r instance, I am in an airport and I see the name of the WiFi AP printed on= the wall an join a network with that SSID. How would you define securely l= earning the DoH server?

-Ekr


-Tiru
=C2=A0

Paul

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000007bf02f05947e82ac-- From nobody Wed Oct 9 11:46: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 6B3A4120120 for ; Wed, 9 Oct 2019 11:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 tRkTvYTrVCyV for ; Wed, 9 Oct 2019 11:46:43 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 20D6512007C for ; Wed, 9 Oct 2019 11:46:43 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 67so2638393oto.3 for ; Wed, 09 Oct 2019 11:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ijd+t6JyHYzshMt+AF0h5bU00bqGmIncnDAB3mnkx04=; b=BdO+NFM1MYGDZxWYOZhNeMFp/ydkchkCfJR4eP0fzMQlUaF5FR+VPuMJ5QT8n9xZJh Nmg51J4ZYi1mQqGAqbCBt0EWjTuo6GJahlEh5f8Hu3nSH1W3GyoWC5o/sE61RjzPQ5c+ 2d213x6ek3cYw2W6zoGEP0Z7eqLMVrccokJAgH3ov9jRbTD4pWuFVjtuX85o3V+KiKSg dRrpXW+8uGWEwa7pn/AKbbITtcpyuEDKOvLq0Kj7HbOcB2GVbdOYvkLsG3zQWFeR1HZe h8V4lxmX9/Q1x3Ogr3Iq5fGl5ChyLEKuCzJ/XSG0xB8UawVXAsBQkPuRnIC3wM69YqmW sAyQ== 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=Ijd+t6JyHYzshMt+AF0h5bU00bqGmIncnDAB3mnkx04=; b=N3bnNXD6W9g0bCqT6Z4zHoic2dRdZEwhNnCfJKczIWkkch6cfljt1nZdnWh3WXCMtD xPqBLC+WWDVwRKK2QwSXO/V55ROUzmv90Tp0bpyihVlyw7+MRoTMSvPfEIeSW6N1oF/g i1eBpdYX9mJTo9qynKr30s17GIp1j0wlArxdMlfBqSywslhCPFOHzwq2he5tAZ4ie1Jy CDx3Dk7W3SfQFL5GQFNsdfEyfeFEneh7Fw9z7EEgsuioXM1ATOFodEdlH0jWxzTYKQgy ABiLrP0mJEKYNPylY6wvNuiTmhOdWpG9hI5Cc9WH6GH6Pifz34faUe00QwMt7wchi3Q2 19gA== X-Gm-Message-State: APjAAAWu9EyFPlEbbP3hx/QzyV283oHTsGtg6YqDJ+KEM+uFTSNZwlDK 15Wk6xwLn4HvtXSO6WKtYgS+E7DPzXXSydtzRLFDgA== X-Google-Smtp-Source: APXvYqzjTmn6S/CoWnWqXWJ6qwUOo20MpnudTDUID/mKBgXBULEcX02KGCrWJBO4WcoCiEhkaoUOZJdGmGJHTrHAAcY= X-Received: by 2002:a9d:6641:: with SMTP id q1mr4302902otm.241.1570646802017; Wed, 09 Oct 2019 11:46:42 -0700 (PDT) MIME-Version: 1.0 References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: From: Richard Barnes Date: Wed, 9 Oct 2019 14:46:29 -0400 Message-ID: To: Eric Rescorla Cc: tirumal reddy , Paul Wouters , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b3fd1705947eb454" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 18:46:46 -0000 --000000000000b3fd1705947eb454 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 2:32 PM Eric Rescorla wrote: > > > On Wed, Oct 9, 2019 at 11:04 AM tirumal reddy wrote: > >> On Wed, 9 Oct 2019 at 18:15, Paul Wouters wrote: >> >>> On Wed, 9 Oct 2019, Eric Rescorla wrote: >>> >>> > You're misunderstanding me. I'm not saying that we should not enable >>> network operators to shift to encrypted transport. >>> > As I said in the section of my message that you cut, I'm more than >>> happy to have the IETF standardize a mechanism for >>> > the network to tell endpoints that it supports encrypted transport. >>> I'm merely observing that this does not address the >>> > issue that Mozilla is trying to address with our DoH/TRR deployment. >>> >>> And it seems doing this at the DHCP / Captive Portal level is enough. I >>> don't see the need for a WG to be spun up for this. >>> >> >> DHCP is not a secure way to discover the local DoT/DoH server. >> > > It would probably useful to start by defining what "secure" means in this > context. For instance, I am in an airport and I see the name of the WiFi AP > printed on the wall an join a network with that SSID. How would you define > securely learning the DoH server? > I would probably be happy with the property that some random other host on the LAN couldn't feed you bad information. Not that this has much to do with DoH. The impact of rogue DHCP servers is just as catastrophic for Do53. --Richard > -Ekr > > >> -Tiru >> >> >>> >>> Paul >>> >>> -- >>> Add mailing list >>> Add@ietf.org >>> https://www.ietf.org/mailman/listinfo/add >>> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000b3fd1705947eb454 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 2:32 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Wed, Oct 9, 2019 at 11:04 AM tirumal reddy <kondtir@gmail.com> = wrote:
On Wed, 9 Oct 2019 at 18:15, Paul Wouters <paul@nohats.ca> wro= te:
On Wed, 9 Oct 2019, Eric Rescorla wrote:

> You're misunderstanding me. I'm not saying that we should not = enable network operators to shift to encrypted transport.
> As I said in the section of my message that you cut, I'm more than= happy to have the IETF standardize a mechanism for
> the network to tell endpoints that it supports encrypted transport. I&= #39;m merely observing that this does not address the
> issue that Mozilla is trying to address with our DoH/TRR deployment.
And it seems doing this at the DHCP / Captive Portal level is enough. I
don't see the need for a WG to be spun up for this.

DHCP is not a secure way to discover the local DoT/DoH ser= ver.

It would probably us= eful to start by defining what "secure" means in this context. Fo= r instance, I am in an airport and I see the name of the WiFi AP printed on= the wall an join a network with that SSID. How would you define securely l= earning the DoH server?

I would probably be happy with the property that some random other host = on the LAN couldn't feed you bad information.

<= div>Not that this has much to do with DoH.=C2=A0 The impact of rogue DHCP s= ervers is just as catastrophic for Do53.

--Ric= hard

=C2=A0
--000000000000b3fd1705947eb454-- From nobody Wed Oct 9 11:55: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 9D870120120 for ; Wed, 9 Oct 2019 11:55:55 -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_HELO_NONE=0.001, 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 aCTvOX1m6fde for ; Wed, 9 Oct 2019 11:55:54 -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 26726120B08 for ; Wed, 9 Oct 2019 11:55:50 -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 0DE216A284; Wed, 9 Oct 2019 20:55:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570647347; bh=t7xhmAdNpd7IfLoAN72aKToVdz5R2x3P9TJude1SAzM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=8i1HcR8j1yIj/tSoFB6s29LhKCOtujyh493QyR1KCYAn3nxC6OMpI6nXMqOsacXXu HU8H6KhBDBN16fnBLtHODs7ha93rSIQrhgm5iZTxBFZkING4Gq9YrJPaA1fn6/VX0i m3uPDi8livaWkcAytWwcQ1Mm3nk4CFsebtMPDPMx0EqJBkRZHbqva3zU7xis0fJPsd 7pUqSDugVqhspQS6KnTAnqXAYGWnOTCkNLUtSvQNC9FtSOlRHr4LDeb5AH/PWj9frd dentTZWTXozSxzcU1+2vJGYJ55ASlZHayO9+HAHhyrs4SzNgKY8IwIDzYa2cts4wRe MUEesCtU/v6Mw== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id E6C0C3C029C; Wed, 9 Oct 2019 20:55:46 +0200 (CEST) Date: Wed, 9 Oct 2019 20:55:46 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Barry Leiba , add@ietf.org Message-ID: <122189477.33003.1570647346845@appsuite-gw1.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 18:55:56 -0000 > Il 9 ottobre 2019 09:38 Barry Leiba ha scritto: > > See the proposal here: > https://trac.tools.ietf.org/bof/trac/wiki/WikiStart I have a clarification question on the last part of the charter, where it gives this objective for a BCP: "- guidelines for deployment models that minimize issues with pervasive monitoring, commercial use of DNS data, and other privacy concerns" Assuming that we want to keep the BCP part in the charter, what is the purpose of listing explicitly those three categories of issues and not others? There are several other types of issues that are created by certain choices of deployment model, e.g. on network security, on jurisdiction, on content/access control, on competition, on centralization... Would these not be minimized by the proposed guidelines? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Oct 9 12:00: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 54F69120BE1 for ; Wed, 9 Oct 2019 12:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q98quU-wQqWd for ; Wed, 9 Oct 2019 12:00:34 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145EF120BDE for ; Wed, 9 Oct 2019 12:00:34 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id r2so2457990lfn.8 for ; Wed, 09 Oct 2019 12:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AIbjh4z2UZ1kY8Y9upGh4vzzzkvW2gwXJK5sP5h1ktg=; b=cOtxZxDbpzcO4y3PYhqt9597EAR5PngCBGMf2uKTINqJ20FDKluvXCMxLnn8ijdV1U 2uQ5X8AUaxz8OsJiPT5Mkj/11AUVqspjoxvlIKvOY5rjMtXQU7AQ865PE4njcHfh+97D KJpLYEooK1sJ6K47gKlVKMCzYMsQaX3VMECJin9ULG72R9UhjLj/19LuBbGbTOUhI23E 8vzdPyCWWnAukQqFhwgkLBk0tRxVfsQpenEjV/O6WsjT8wnVXCrM30a10JvSDqx6DyzY OUlNTPNPoEWShqy7uqb0dUcEg4IAKdqan30rDOv4jGgtUa5jk3Tf/zWK2cuirs7zundt RjoQ== 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=AIbjh4z2UZ1kY8Y9upGh4vzzzkvW2gwXJK5sP5h1ktg=; b=lCpOg8NwXnp3onnxkXDV6VMN0tnF2qeFPbZyuT3yHyA0XanPudOxRhofK5GAisniMG ENSn2Z3GY+VLDXxQSIS4/V2E84hPHgbmoc4wZWwNABVMfhZua2DajF7rL7YDg4fVcaFm 1WiDbXjlXwVnKAcpMIgh0PZsqv9OuBcxjfOm6ZqWdK+7gUM3agEWG+dDZXWt9KqhTIpJ 0RUQPRXDnCCsr/TNGdG8Q60INrgTCRkfF9V8gFbJfrK/KW8uZNyhfGxGZXdgMAcSGGVx ionspHvBu7xnk4MJ0zSFRzX3VYkr2j3H1U07kOE/zgv61W/o1F5hIPeqdulwIZohi9H6 zf3A== X-Gm-Message-State: APjAAAWpNQ4WZLKKjE+6O9W7xJit80pdkeKXgjhfLWLzf0jW5+yCv0db 2HyMxtiV+FoNFouGofhsHXFuK3j/w0lQ21cQMBOuGw== X-Google-Smtp-Source: APXvYqx+5siEbutIU/bz/0n2slMXuZHg2b0MojJzMW8ewRdurw0fMd75gDWWZlYP4xCxAVUFRn4REOMysnf2QnNmtMY= X-Received: by 2002:a19:84c:: with SMTP id 73mr3046998lfi.180.1570647632142; Wed, 09 Oct 2019 12:00:32 -0700 (PDT) MIME-Version: 1.0 References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 11:59:54 -0700 Message-ID: To: Richard Barnes Cc: tirumal reddy , Paul Wouters , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002e75fe05947ee6b7" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 19:00:45 -0000 --0000000000002e75fe05947ee6b7 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 11:46 AM Richard Barnes wrote: > > > On Wed, Oct 9, 2019 at 2:32 PM Eric Rescorla wrote: > >> >> >> On Wed, Oct 9, 2019 at 11:04 AM tirumal reddy wrote: >> >>> On Wed, 9 Oct 2019 at 18:15, Paul Wouters wrote: >>> >>>> On Wed, 9 Oct 2019, Eric Rescorla wrote: >>>> >>>> > You're misunderstanding me. I'm not saying that we should not enable >>>> network operators to shift to encrypted transport. >>>> > As I said in the section of my message that you cut, I'm more than >>>> happy to have the IETF standardize a mechanism for >>>> > the network to tell endpoints that it supports encrypted transport. >>>> I'm merely observing that this does not address the >>>> > issue that Mozilla is trying to address with our DoH/TRR deployment. >>>> >>>> And it seems doing this at the DHCP / Captive Portal level is enough. I >>>> don't see the need for a WG to be spun up for this. >>>> >>> >>> DHCP is not a secure way to discover the local DoT/DoH server. >>> >> >> It would probably useful to start by defining what "secure" means in this >> context. For instance, I am in an airport and I see the name of the WiFi AP >> printed on the wall an join a network with that SSID. How would you define >> securely learning the DoH server? >> > > I would probably be happy with the property that some random other host on > the LAN couldn't feed you bad information. > Yeah, I'm not actually sure how to do that without making some assumptions about the LAN structure and (in the case of wireless, what kind of crypto was in place). > Not that this has much to do with DoH. The impact of rogue DHCP servers > is just as catastrophic for Do53. > Well, perhaps less, because the Do53 security properties are already so terrible :) -Ekr --0000000000002e75fe05947ee6b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 11:46 AM Richa= rd Barnes <rlb@ipv.sx> wrote:


On Wed, Oct 9, 20= 19 at 2:32 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, Oct 9, 201= 9 at 11:04 AM tirumal reddy <kondtir@gmail.com> wrote:
On Wed, 9 Oc= t 2019 at 18:15, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 9 Oct 2019, Er= ic Rescorla wrote:

> You're misunderstanding me. I'm not saying that we should not = enable network operators to shift to encrypted transport.
> As I said in the section of my message that you cut, I'm more than= happy to have the IETF standardize a mechanism for
> the network to tell endpoints that it supports encrypted transport. I&= #39;m merely observing that this does not address the
> issue that Mozilla is trying to address with our DoH/TRR deployment.
And it seems doing this at the DHCP / Captive Portal level is enough. I
don't see the need for a WG to be spun up for this.

DHCP is not a secure way to discover the local DoT/DoH ser= ver.

It would probably us= eful to start by defining what "secure" means in this context. Fo= r instance, I am in an airport and I see the name of the WiFi AP printed on= the wall an join a network with that SSID. How would you define securely l= earning the DoH server?

I would probably be happy with the property that some random other host = on the LAN couldn't feed you bad information.

Yeah, I'm not actually sure how to do that= without making some assumptions about the LAN structure and (in the case o= f wireless, what kind of crypto was in place).


Not that this has much to do wit= h DoH.=C2=A0 The impact of rogue DHCP servers is just as catastrophic for D= o53.

Well, perhaps le= ss, because the Do53 security properties are already so terrible :)

-Ekr
--0000000000002e75fe05947ee6b7-- From nobody Wed Oct 9 12:16: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 66420120B1D for ; Wed, 9 Oct 2019 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 eGQwEx5GKweZ for ; Wed, 9 Oct 2019 12:16:30 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE7F120B1F for ; Wed, 9 Oct 2019 12:16:12 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 7C597242141F; Wed, 9 Oct 2019 19:16:09 +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: Wed, 9 Oct 2019 20:16:08 +0100 Cc: Paul Wouters , ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> To: tirumal reddy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 19:16:31 -0000 > On 9 Oct 2019, at 19:04, tirumal reddy wrote: >=20 > DHCP is not a secure way to discover the local DoT/DoH server. That may well be true. However that debate belongs on another thread and = maybe even another list. I thought we were meant to be discussing the proposed charter for a new = WG and a possible BoF in Singapore. Could we please focus on that? Debating the detail of DHCP/discovery methods seems to be off-topic for = the matter at hand. Though these could well be the basis of new work if = and when the ABCD is formed. From nobody Wed Oct 9 12:25: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 149E4120B22 for ; Wed, 9 Oct 2019 12:25:35 -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_HELO_NONE=0.001, 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 srw2qDYPv8-3 for ; Wed, 9 Oct 2019 12:25:33 -0700 (PDT) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771AB120B1F for ; Wed, 9 Oct 2019 12:25:32 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 49FB78DED0; Wed, 9 Oct 2019 15:25:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23966.13355.285067.876210@gro.dd.org> Date: Wed, 9 Oct 2019 15:25:31 -0400 From: Dave Lawrence To: ADD Mailing list In-Reply-To: <8DE3BAFF-9D6B-494E-89CA-6C5F89FA10D6@senki.org> References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> <23964.55791.591141.356687@gro.dd.org> <8DE3BAFF-9D6B-494E-89CA-6C5F89FA10D6@senki.org> Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 19:25:35 -0000 Ted Lemon writes: >> Why do you think botnets bother to use DNS to find C&C controllers, >> even though DNS has been being used as a way to mitigate malware for >> years? If they could do it some other way, wouldn t they have done so? Barry Greene writes: > The reaction by the security community is the core reason miscreants > moved to DNS and DGA [...] Then the miscreants shifted their C&C to > DGAs and Fast-Flux. Right, going back to my original statement about malware using DNS, "they still do because the mitigations haven't been effective enough," this was what I was driving at. I didn't say DNS controls were completely ineffective, but they've not been enough of an obstacle for the malware to stop using DNS. With necessity being the mother of invention, malware authors haven't had enough compelling reason to develop widespread workarounds to DNS controls because they can still get along well enough in the current environment with the good guys doing clear-text DNS filtering. It's not because of a lack of possibilities that aren't the DNS. I'm sure a non-trivial number of people on this list could come up with some non-DNS methods pretty quickly. From nobody Wed Oct 9 12:59: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 8C4B4120D00 for ; Wed, 9 Oct 2019 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 XVnL1hwniYYW for ; Wed, 9 Oct 2019 12:59:55 -0700 (PDT) Received: from smtp123.ord1d.emailsrvr.com (smtp123.ord1d.emailsrvr.com [184.106.54.123]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440A3120C41 for ; Wed, 9 Oct 2019 12:59:55 -0700 (PDT) X-Auth-ID: bgreene@senki.org Received: by smtp24.relay.ord1d.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 3D11BA02D7; Wed, 9 Oct 2019 15:59:54 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [10.0.0.246] (c-73-15-67-108.hsd1.ca.comcast.net [73.15.67.108]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 09 Oct 2019 15:59:54 -0400 From: Barry Greene Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C13A0E60-2C51-45A5-A780-231B73E5D7AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 9 Oct 2019 12:59:52 -0700 In-Reply-To: <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> Cc: Joe Abley , ADD Mailing list , David Lawrence To: Ted Lemon References: <7ABDABF3-2AE4-405D-9B14-407B88D33025@senki.org> <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 19:59:57 -0000 --Apple-Mail=_C13A0E60-2C51-45A5-A780-231B73E5D7AF Content-Type: multipart/alternative; boundary="Apple-Mail=_DFE51377-BE0E-426A-927F-38EC6D3678C5" --Apple-Mail=_DFE51377-BE0E-426A-927F-38EC6D3678C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2019, at 9:27 AM, Ted Lemon wrote: >=20 > You misunderstand my point. I mean that a security researcher with = one of these devices in their lab should be able to notice miscreants. = E.g., why is my Nest camera connecting to that server in East Agulfia? = Nest isn=E2=80=99t in East Agulfia. For constrained devices this = isn=E2=80=99t even a challenge. The problem with these devices is that = at present in most cases no such constraints are applied to them. Mud = does a pretty good job of solving this problem. I understand your point. Good malware systems test for sandbox, = honeypots, and other =E2=80=9Clab=E2=80=9D work. This defeats the = average security researcher. Of course, the volume of bad malware with = easy detection is the majority - overwhelming the industry to be able to = spot, build IOC, and get the word out to the filtering tools (which = include DNS resolvers). The problem I=E2=80=99m having with this whole discussion is the small = group pushing for the community to =E2=80=9Cthrow away the screwdriver = from my toolbox =E2=80=A6 a hammer is just as effective to hammer in = screws.=E2=80=9D Battling the miscreant threat should be expanding the = security toolbox, not limiting it. Irony - we did all this work in IETF for IPFIX - with security as the = core driver - to give us detailed visibility into what is happening on = the network. There is a bigger =E2=80=9Csecurity threat=E2=80=9D from = IETF=E2=80=99s IPFIX than there is from some =E2=80=9Chypothetical DNS = wiretap=E2=80=9D between the Stub Resolver and the resolver. --Apple-Mail=_DFE51377-BE0E-426A-927F-38EC6D3678C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 9, 2019, at 9:27 AM, Ted Lemon <mellon@fugue.com> = wrote:

You misunderstand my point. =   I mean that a security researcher with one of these devices in = their lab should be able to notice miscreants.   E.g., why is my = Nest camera connecting to that server in East Agulfia?   Nest = isn=E2=80=99t in East Agulfia.   For constrained devices this = isn=E2=80=99t even a challenge.   The problem with these devices is = that at present in most cases no such constraints are applied to them. =  Mud does a pretty good job of solving this = problem.

I = understand your point. Good malware systems test for sandbox, honeypots, = and other =E2=80=9Clab=E2=80=9D work. This defeats the average security = researcher. Of course, the volume of bad malware with easy detection is = the majority - overwhelming the industry to be able to spot, build IOC, = and get the word out to the filtering tools (which include DNS = resolvers). 

The problem I=E2=80=99m having with this whole discussion is = the small group pushing for the community to =E2=80=9Cthrow away the = screwdriver from my toolbox =E2=80=A6 a hammer is just as effective to = hammer in screws.=E2=80=9D Battling the miscreant threat should be = expanding the security toolbox, not limiting it. 

Irony - we did all this = work in IETF for IPFIX - with security as the core driver - to give us = detailed visibility into what is happening on the network. There is a = bigger =E2=80=9Csecurity threat=E2=80=9D from IETF=E2=80=99s IPFIX than = there is from some =E2=80=9Chypothetical DNS wiretap=E2=80=9D between = the Stub Resolver and the resolver. 

 


= --Apple-Mail=_DFE51377-BE0E-426A-927F-38EC6D3678C5-- --Apple-Mail=_C13A0E60-2C51-45A5-A780-231B73E5D7AF 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----- iQEzBAEBCgAdFiEEdoGA/YBcwd1ud+j1VW6TcBa/RfMFAl2ePDgACgkQVW6TcBa/ RfMvGgf7B5R8T1l+FEmRlfi6fA9i3yv8kkDyJQI8/34g6GWbS8gG4+GBs47ugW92 ZQ4X5XAWZjbr8hdXHFHiGqz+Hij+xlJr1wWuE2fflM3H4DbjzUzCpZhl/YoQisfh t0BAEHxG5dGFCOS/Fpj6YsJ/obonvxVuzEpSbeQgQDflso8gCaaumOkl57idygvU boKSrGdm3Xz42u2M3aP6JLIgNU87JsBNyaoI6JR9uqwog6RjqaF+vKvMrJmfp85r WgLOK7keesmpSEjYruVss1Ts5AtnwgL5gU0uldB/ZQCG+7XkwiiKUPUUtdaEhKak kZA8vmaaOYyX2UqGkvMwWn2GLUp3fA== =SJTI -----END PGP SIGNATURE----- --Apple-Mail=_C13A0E60-2C51-45A5-A780-231B73E5D7AF-- From nobody Wed Oct 9 13:06: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 408221200E6 for ; Wed, 9 Oct 2019 13:06:43 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 UebentZPY9yf for ; Wed, 9 Oct 2019 13:06:39 -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 001AE12004F for ; Wed, 9 Oct 2019 13:06:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pQGM5ntQzFbJ; Wed, 9 Oct 2019 22:06:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570651595; bh=JyZSd76fzhCp1ErLBKzj6uiXS+PiAl6PYEOjwzRuwmc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=elSX4Rta3JmYPFNmKGTjR8A99bS64C0VSdSrlliEZ78kz65Tjwrvfu9Qvzq6dv5tm Np8FTOkLiouZz/XoJGW+A2PkvpfzDF/nN/lwTCgYV7yUd4t/vmM0Lzr9Wd4fLJTckF Vlt28plHgFpHZU7hFSPonJ0x+q1guxeb0IsLN4+0= 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 UDQ2XO4MCRPy; Wed, 9 Oct 2019 22:06:34 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 9 Oct 2019 22:06:34 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B00CE607F2CB; Wed, 9 Oct 2019 16:06:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AE9BF65E60; Wed, 9 Oct 2019 16:06:33 -0400 (EDT) Date: Wed, 9 Oct 2019 16:06:33 -0400 (EDT) From: Paul Wouters To: Barry Greene cc: ADD Mailing list In-Reply-To: Message-ID: References: <7ABDABF3-2AE4-405D-9B14-407B88D33025@senki.org> <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 20:06:43 -0000 On Wed, 9 Oct 2019, Barry Greene wrote: > The problem I’m having with this whole discussion is the small group pushing for the community to “throw away > the screwdriver from my toolbox … a hammer is just as effective to hammer in screws.” Battling the miscreant > threat should be expanding the security toolbox, not limiting it.  It's not a "tool" that is taken away from you. It's a leaking water pipe. And you are arguing that you cannot see if the water is contaminated anymore because the pipe got fixed. Paul From nobody Wed Oct 9 13:10: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 BA4AC1200E6 for ; Wed, 9 Oct 2019 13:10:52 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 I953W9zo-mZP for ; Wed, 9 Oct 2019 13:10:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 9BDC812004F for ; Wed, 9 Oct 2019 13:10:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pQMG1bF4zFbG; Wed, 9 Oct 2019 22:10:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570651850; bh=5+FzeKX88X2zoLAKta5j022Ao+NcFZKJ0yJOgMNN57g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XmaQzQ5pNynGIy84/jXPRqxTfIgfgQxgST1rjKSXBHnwubxAuf+7PzK5+p1F9bNgo RuXT/Lpt0Om/m1rfQAvmTUfYRrp9ROP20AeqbIKXG8iGT8GHni+MpqtJEertfoALes yrXoQErnTD00m8H4HKkZyIidwB8U8fD60hmQWZzI= 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 RSe46CGcrFU3; Wed, 9 Oct 2019 22:10:49 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 9 Oct 2019 22:10:49 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5D533607F2CB; Wed, 9 Oct 2019 16:10:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5C28F65E60; Wed, 9 Oct 2019 16:10:48 -0400 (EDT) Date: Wed, 9 Oct 2019 16:10:48 -0400 (EDT) From: Paul Wouters To: Dave Lawrence cc: ADD Mailing list In-Reply-To: <23966.13355.285067.876210@gro.dd.org> Message-ID: References: <052D6ED6-9DE9-4F9C-86D6-25B6888EDDA5@fugue.com> <2FA930D0-A0AC-4015-8D88-A5B2C33EB1C4@fugue.com> <23964.55791.591141.356687@gro.dd.org> <8DE3BAFF-9D6B-494E-89CA-6C5F89FA10D6@senki.org> <23966.13355.285067.876210@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 09 Oct 2019 20:10:53 -0000 On Wed, 9 Oct 2019, Dave Lawrence wrote: > I didn't say DNS controls were completely ineffective, but they've not > been enough of an obstacle for the malware to stop using DNS. With > necessity being the mother of invention, malware authors haven't had > enough compelling reason to develop widespread workarounds to DNS > controls because they can still get along well enough in the current > environment with the good guys doing clear-text DNS filtering. It's > not because of a lack of possibilities that aren't the DNS. I'm sure > a non-trivial number of people on this list could come up with some > non-DNS methods pretty quickly. But even if you want to keep using DNS, write a browser plugin that people can optin to that sits in the DNS resolving path in the browser. Note that this means it is optin, per-user and no one will be forced this tool as a censorship tool. This tool could use the existing RPZ infrastructure (and cache too so the latency cost should be low) There is no need for the network to keep leaking clear DNS. The application has access to the plain DNS. Paul From nobody Wed Oct 9 13:24: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 99265120B22 for ; Wed, 9 Oct 2019 13:24:27 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 B0XC4uAYIZRG for ; Wed, 9 Oct 2019 13:24:26 -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 14ECD12004F for ; Wed, 9 Oct 2019 13:24:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pQfv0VLwzFbJ for ; Wed, 9 Oct 2019 22:24:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570652663; bh=O7cewJRCsUiWh7nG/vXr9OPTA6eh0xwwdxCWqnuIgEA=; h=Date:From:To:Subject:In-Reply-To:References; b=GGHENmufrpO1Iwxc+mWIHq6V0+FvoxFLtTaYw0HEiNCaik7Z9cB1dmqFRXJUMvEkH srk2U9X8/iHTKY6M3qvGicA4vEbvvfYq7jvabKJp3y7zfmR6NX7E7uANA1W7GiTyBr p0Kawu7GeWfY7eRjCxvtYsoqvoayeb3vMG06i680= 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 WQlhojClG4ke for ; Wed, 9 Oct 2019 22:24:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 9 Oct 2019 22:24:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 81EA4607F2CB; Wed, 9 Oct 2019 16:24:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7E29723FE47 for ; Wed, 9 Oct 2019 16:24:20 -0400 (EDT) Date: Wed, 9 Oct 2019 16:24:20 -0400 (EDT) From: Paul Wouters To: add@ietf.org In-Reply-To: Message-ID: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 20:24:28 -0000 On Wed, 9 Oct 2019, Jim Reid wrote: >> On 9 Oct 2019, at 19:04, tirumal reddy wrote: >> >> DHCP is not a secure way to discover the local DoT/DoH server. > > That may well be true. However that debate belongs on another thread and maybe even another list. > > I thought we were meant to be discussing the proposed charter for a new WG and a possible BoF in Singapore. Could we please focus on that? It is relevant, because if we believe the only thing that is needed is a DHCP option, then we do not need to spin up a working group. In fact, I would expect whoever wants to spin up a new group to have done some preliminary work in this area so that it is clear there is a real large enough problem to be solved using a WG. I don't get the feeling this happened. What I see is people looking for a business model for "secure DNS" services. I don't think that business model needs protocol level support from the IETF (because as I stated earlier, consumer trust doesn't work by signed XML statements). Compare this with starting up a WG to eavesdrop on TLS 1.3 traffic. Look at how PATIENT hasn't seen any discussion since July 2018. We didn't start a WG for that either. Why should we do one on eavedropping encrypted DNS? As for the "DHCP is not secure" argument. There is absolutely no expectation of validatable security when someone joins a random network. When I join a known preconfigured enterprise network, I already have trust anchors. When I decide to trust a personal DoH server that is not local, I already have the trust anchors I need as well. An insecure DHCP option is useful for the enterprise/parental use case, where just being on the network is a veriably secure action already. Paul From nobody Wed Oct 9 13:57: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 97E30120B22 for ; Wed, 9 Oct 2019 13:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=C+Zk54ro; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PpByNozD 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 lYA3yLndq3uW for ; Wed, 9 Oct 2019 13:57:09 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DDE12004F for ; Wed, 9 Oct 2019 13:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3034; q=dns/txt; s=iport; t=1570654603; x=1571864203; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=r1w0SVrR6CJ7WXZTsI88X+OvmNq7Hhe6W7Qu+c0nTcQ=; b=C+Zk54romaRefSEUtWIEy7KGpPjeQB6KxHWakjgMIX6u9fu1XzApPLlW XuR6cvW1I24hBJ8zzYuHr5Q4Fncv9RHPoj2AX9ijJdDKjTqiDWg2xEibS 3itZJ176r6+hZqth8XinKA+DbQfUZf/TwlgTZN7XPK6pj1sMHd8WRXQ+9 s=; IronPort-PHdr: =?us-ascii?q?9a23=3AdoeDlBBS6pds6aRSrEILUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAwAASJ5d/4cNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4FLJCwFbFYgBAsqhCNigmUDikVNgWoliWqOE4JSA1Q?= =?us-ascii?q?JAQEBDAEBGAsKAgEBhEACF4I4IzgTAgMJAQEEAQEBAgEFBG2FLQyFSwEBAQE?= =?us-ascii?q?CAQEBEBERDAEBLAwPAgEIGAICJgICAh8GCxUQAgQBEiKDAAGCRgMOIAECDKY?= =?us-ascii?q?rAoE4iGF1gTKCfQEBBYJJgj8NC4IXAwaBDCiLcR0YgUA/gTgME4IeLj5rGQG?= =?us-ascii?q?BFUcBAYFLLYJ3MoIsj2+dF0EKgiKREYQIG4I6h06POI4tijCPBgIEAgQFAg4?= =?us-ascii?q?BAQWBaSKBWHAVOyoBgkFQEBSBTwwMC4NQhRSFP3SBKY0gK4InAQE?= X-IronPort-AV: E=Sophos;i="5.67,277,1566864000"; d="scan'208";a="346947912" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2019 20:56:42 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x99Kug98031823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2019 20:56:42 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 15:56:41 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 15:56:40 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 9 Oct 2019 15:56:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oWheyp1AU0tdIsJCv4KqZioYv5taWD6CcRiY+He8q9923sgdcb/C9/oH3ICtntiffluSer7YDC01G/qzqswj/ZT/egDWMIQi1uuyZgcMTaikcfSJwuh61+r2tQOpaR1MKWL5Zn0+hMVg8q7p4h11G2V+kX22p9DW+D1llq9nVxBySnudTXq6PZG3AXTOjFQ+zPC8doaVpcLKJKiTAb3KjiCayJfgj080jJhSzVnMWnJBq5kHcboz3EVnX8M+htrOxbtt0UjvBNVyXrSX09CM3lVj9N84xU0rdUZMzi/xI1xNOtZpA/kLMciebJ3iIOp1erlfoWSZhOYK01AgVdmjUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r1w0SVrR6CJ7WXZTsI88X+OvmNq7Hhe6W7Qu+c0nTcQ=; b=eGvw8ZECGmwaFhRpwcOYcws6eIHTTaAXJO0XjxldhjMNUQXaTvdgx7XknOHSaHRCYUk/CBXG9Lul5+2xSZLURXplY3Z9CKBY7HJDihUswViODUPZbwlsAbHZAO8xaJi1UbqY7ufSktj/K65Xtgxr6zbxSPbqmYgDCdi4IG+1ir1pzk2fSLHBr7b/gsjsUV2Tytyy16xbMHTkBYZZ1af8fp0pGKjv1xBHWNKOjRZQsYDAXDTfq5oPFHCNRfTeslCpof0dBibU9zu/uZLrzotr1ydsTmRmxYBy8gKpC1POWJX5v+iP3Jsy/VbCfVZPn9GT09bTC8pWa69L5BzBashDXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r1w0SVrR6CJ7WXZTsI88X+OvmNq7Hhe6W7Qu+c0nTcQ=; b=PpByNozDsy3FaQbw13fPwCJgmZCLwL/92UsFizc9raY3K1DhqoniHX0vAS966d0zc9BYP1dePyQqduYtVsbxpLpH5cpEk//063G+E6m+oChAX/+F7ATlil5AEw6wmTNpxYeDavNTT1hSvbe380SPBihdXoTROO/4RVIKPcKaD64= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3982.namprd11.prod.outlook.com (10.255.181.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Wed, 9 Oct 2019 20:56:39 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2347.016; Wed, 9 Oct 2019 20:56:39 +0000 From: "Eric Vyncke (evyncke)" To: Paul Wouters , "add@ietf.org" Thread-Topic: [Add] Proposed charter and BoF request for IETF 106 Thread-Index: AQHVfnSkBrNlnq14+kme+Fb6LfA+b6dSNM6AgABTSICAAAJggIAAAuOAgAANqYCAABQWAIAAEw4AgAAqjQA= Date: Wed, 9 Oct 2019 20:56:39 +0000 Message-ID: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c0:1006::32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e11cd7de-6cab-4089-19cc-08d74cfb2e83 x-ms-traffictypediagnostic: MN2PR11MB3982: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(199004)(189003)(66946007)(110136005)(8936002)(71190400001)(2501003)(6486002)(66476007)(11346002)(446003)(476003)(46003)(7736002)(2616005)(186003)(486006)(71200400001)(91956017)(76116006)(64756008)(66446008)(66556008)(81156014)(6116002)(14444005)(81166006)(316002)(25786009)(256004)(8676002)(58126008)(229853002)(2906002)(14454004)(6246003)(6436002)(6512007)(6306002)(478600001)(305945005)(33656002)(86362001)(966005)(76176011)(6506007)(36756003)(99286004)(5660300002)(102836004)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3982; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7E3rB6NKXgxbc6h5WK035jsRsxns+Pw0CPvR7mrzLhobAvwyEseOlmQKNWDyafYu7IxF0MybUQh7h9MWZhXaHTvpLOj8G8yFuxFOjZnHL1LqvQy2qk+6Mq8CvPynxv/XUDq+tEQ8b9ij6tYgVKsjC9PgZZluHKHhWahY5Wy3fr6aqPsAoOIjfJPobpZkpGWbUfWDNDKLcwQHwruJs2e4N09K9ElnmyJxx/sW8IggOVvL/Nwxlbw0woj0JtK/GPn76rKgEYugPmMuIW6vzVufEHZPKAWFyySrma90fwDIG7PWhVeqXl0/RSSPBlH+PJ4V+VdCE+MaSYuUnoWewYa9OOREQtDJwz4dhc6UqDOdItjbE3UfYpfmjdFizgbEa/5N3IoLCfV5q1/+gBmehyTE1RS295YhwC/405MCzDEjzUBIB/pcunIo8sGA36M5YaWaGoWzQX3TvtUPRIyEfltU5Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <06B5ACC61BEF9C47A9C9841C2BABA9BB@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e11cd7de-6cab-4089-19cc-08d74cfb2e83 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 20:56:39.5511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Xg3w7gfUS2yyghHp4cZCxlpj8ZsGqSgi90/0LRQsBbWF0K+b6WmAz/QWaDPK8YnLkD6qoh+NrUS3llF1FBjWbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3982 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 20:57:12 -0000 QW5kIEJUVyBkbyBub3QgZm9yZ2V0IHRoYXQgaW4gSVB2NiB0aGUgcHJvbWluZW5jZSBvZiBESENQ IGlzIGNsb3NlIHRvIDAgOy0pDQoNCi3DqXJpYw0KDQrvu79PbiAwOS8xMC8yMDE5LCAyMjoyNCwg IkFkZCBvbiBiZWhhbGYgb2YgUGF1bCBXb3V0ZXJzIiA8YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIHBhdWxAbm9oYXRzLmNhPiB3cm90ZToNCg0KICAgIE9uIFdlZCwgOSBPY3QgMjAx OSwgSmltIFJlaWQgd3JvdGU6DQogICAgDQogICAgPj4gT24gOSBPY3QgMjAxOSwgYXQgMTk6MDQs IHRpcnVtYWwgcmVkZHkgPGtvbmR0aXJAZ21haWwuY29tPiB3cm90ZToNCiAgICA+Pg0KICAgID4+ IERIQ1AgaXMgbm90IGEgc2VjdXJlIHdheSB0byBkaXNjb3ZlciB0aGUgbG9jYWwgRG9UL0RvSCBz ZXJ2ZXIuDQogICAgPg0KICAgID4gVGhhdCBtYXkgd2VsbCBiZSB0cnVlLiBIb3dldmVyIHRoYXQg ZGViYXRlIGJlbG9uZ3Mgb24gYW5vdGhlciB0aHJlYWQgYW5kIG1heWJlIGV2ZW4gYW5vdGhlciBs aXN0Lg0KICAgID4NCiAgICA+IEkgdGhvdWdodCB3ZSB3ZXJlIG1lYW50IHRvIGJlIGRpc2N1c3Np bmcgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgZm9yIGEgbmV3IFdHIGFuZCBhIHBvc3NpYmxlIEJvRiBp biBTaW5nYXBvcmUuIENvdWxkIHdlIHBsZWFzZSBmb2N1cyBvbiB0aGF0Pw0KICAgIA0KICAgIEl0 IGlzIHJlbGV2YW50LCBiZWNhdXNlIGlmIHdlIGJlbGlldmUgdGhlIG9ubHkgdGhpbmcgdGhhdCBp cyBuZWVkZWQgaXMNCiAgICBhIERIQ1Agb3B0aW9uLCB0aGVuIHdlIGRvIG5vdCBuZWVkIHRvIHNw aW4gdXAgYSB3b3JraW5nIGdyb3VwLiBJbiBmYWN0LA0KICAgIEkgd291bGQgZXhwZWN0IHdob2V2 ZXIgd2FudHMgdG8gc3BpbiB1cCBhIG5ldyBncm91cCB0byBoYXZlIGRvbmUgc29tZQ0KICAgIHBy ZWxpbWluYXJ5IHdvcmsgaW4gdGhpcyBhcmVhIHNvIHRoYXQgaXQgaXMgY2xlYXIgdGhlcmUgaXMg YSByZWFsIGxhcmdlDQogICAgZW5vdWdoIHByb2JsZW0gdG8gYmUgc29sdmVkIHVzaW5nIGEgV0cu IEkgZG9uJ3QgZ2V0IHRoZSBmZWVsaW5nIHRoaXMNCiAgICBoYXBwZW5lZC4gV2hhdCBJIHNlZSBp cyBwZW9wbGUgbG9va2luZyBmb3IgYSBidXNpbmVzcyBtb2RlbCBmb3IgInNlY3VyZQ0KICAgIERO UyIgc2VydmljZXMuIEkgZG9uJ3QgdGhpbmsgdGhhdCBidXNpbmVzcyBtb2RlbCBuZWVkcyBwcm90 b2NvbCBsZXZlbA0KICAgIHN1cHBvcnQgZnJvbSB0aGUgSUVURiAoYmVjYXVzZSBhcyBJIHN0YXRl ZCBlYXJsaWVyLCBjb25zdW1lciB0cnVzdA0KICAgIGRvZXNuJ3Qgd29yayBieSBzaWduZWQgWE1M IHN0YXRlbWVudHMpLg0KICAgIA0KICAgIENvbXBhcmUgdGhpcyB3aXRoIHN0YXJ0aW5nIHVwIGEg V0cgdG8gZWF2ZXNkcm9wIG9uIFRMUyAxLjMgdHJhZmZpYy4NCiAgICBMb29rIGF0IGhvdyBQQVRJ RU5UIGhhc24ndCBzZWVuIGFueSBkaXNjdXNzaW9uIHNpbmNlIEp1bHkgMjAxOC4gV2UNCiAgICBk aWRuJ3Qgc3RhcnQgYSBXRyBmb3IgdGhhdCBlaXRoZXIuIFdoeSBzaG91bGQgd2UgZG8gb25lIG9u IGVhdmVkcm9wcGluZw0KICAgIGVuY3J5cHRlZCBETlM/DQogICAgDQogICAgQXMgZm9yIHRoZSAi REhDUCBpcyBub3Qgc2VjdXJlIiBhcmd1bWVudC4gVGhlcmUgaXMgYWJzb2x1dGVseSBubw0KICAg IGV4cGVjdGF0aW9uIG9mIHZhbGlkYXRhYmxlIHNlY3VyaXR5IHdoZW4gc29tZW9uZSBqb2lucyBh IHJhbmRvbQ0KICAgIG5ldHdvcmsuIFdoZW4gSSBqb2luIGEga25vd24gcHJlY29uZmlndXJlZCBl bnRlcnByaXNlIG5ldHdvcmssIEkgYWxyZWFkeQ0KICAgIGhhdmUgdHJ1c3QgYW5jaG9ycy4gV2hl biBJIGRlY2lkZSB0byB0cnVzdCBhIHBlcnNvbmFsIERvSCBzZXJ2ZXIgdGhhdCBpcw0KICAgIG5v dCBsb2NhbCwgSSBhbHJlYWR5IGhhdmUgdGhlIHRydXN0IGFuY2hvcnMgSSBuZWVkIGFzIHdlbGwu IEFuIGluc2VjdXJlDQogICAgREhDUCBvcHRpb24gaXMgdXNlZnVsIGZvciB0aGUgZW50ZXJwcmlz ZS9wYXJlbnRhbCB1c2UgY2FzZSwgd2hlcmUganVzdA0KICAgIGJlaW5nIG9uIHRoZSBuZXR3b3Jr IGlzIGEgdmVyaWFibHkgc2VjdXJlIGFjdGlvbiBhbHJlYWR5Lg0KICAgIA0KICAgIFBhdWwNCiAg ICANCiAgICAtLSANCiAgICBBZGQgbWFpbGluZyBsaXN0DQogICAgQWRkQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGQNCiAgICANCg0K From nobody Wed Oct 9 14:35: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 E2481120834 for ; Wed, 9 Oct 2019 14:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 K6-zIXkP8h1z for ; Wed, 9 Oct 2019 14:35:15 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F9A120058 for ; Wed, 9 Oct 2019 14:35:14 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 0F8EB2420FDE; Wed, 9 Oct 2019 21:35:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Wed, 9 Oct 2019 22:35:10 +0100 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 21:35:16 -0000 > On 9 Oct 2019, at 21:24, Paul Wouters wrote: >=20 > Why should we do one on eavedropping encrypted DNS? What part of the proposed charter implies that=E2=80=99s what this new = WG would do? From nobody Wed Oct 9 14:47: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 3B06B12084F for ; Wed, 9 Oct 2019 14:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 flv-dKmlghV3 for ; Wed, 9 Oct 2019 14:47:02 -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 19146120043 for ; Wed, 9 Oct 2019 14:47:02 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 9368B2420FDE; Wed, 9 Oct 2019 21:46:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Wed, 9 Oct 2019 22:46:58 +0100 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 21:47:03 -0000 > On 9 Oct 2019, at 21:24, Paul Wouters wrote: >=20 > It is relevant, because if we believe the only thing that is needed is > a DHCP option, then we do not need to spin up a working group. Well the draft charter says: Specific initial areas of focus include but are not limited to: - Resolver discovery and selection - Expression of resolver policy - Support for split-horizon DNS environments - Mechanisms to facilitate testing of new configurations Only the first item on that list looks is if it could somehow touch on = DHCP. And even then it might only have an impact on DHCP if the current = discovery draft in the doh WG fails to deliver. So no, a DHCP option is = not the only thing that=E2=80=99s needed IMO. I would also hope we can agree to take an objective, evidence-based = approach rather than one which is based on subjective matters of belief. From nobody Wed Oct 9 15:41: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 0923C12008A for ; Wed, 9 Oct 2019 15:41:27 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb2Le0TVlwVg for ; Wed, 9 Oct 2019 15:41:25 -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 1B49B12004C for ; Wed, 9 Oct 2019 15:41:25 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id 4so3784934qki.6 for ; Wed, 09 Oct 2019 15:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YcgpYFDF3NOj2vdLHXRgyHEnoiIl6XfKxUjxLWnEf3A=; b=qT0VCP92KrzeKulaf5dCDn++PECsBS03omwy31aLGc6noI2wtfwEwsRemJDQOfXAtI UmRBZhzlLWNwmnvaLVsdmBlnvwzdeIVxGzF1pydVgc4lPX186ALTOzNYUSG+4HwHGx1e XoH2MyUheW8qH4zft+iiPfHCEsBG/XHApRjQDBK0mJcuJ8QtaDHvpOSFc/BxlFH0GFxi tNeYiTwmdsd/9NkQiAtxImEnvALMGb8gODe2ivhD1XUnEGTgTgVffAEIGNOR/EMtI/WP hjKK/o02Qqy0M2TmtQilSGBdLK68r2oqEqQJwfuCgdivfLwLr5znGbGbMn2vWRUCY7rU 9EKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YcgpYFDF3NOj2vdLHXRgyHEnoiIl6XfKxUjxLWnEf3A=; b=Asx8PDIPK4jlX6998XiezVx5WgKVdkXfxQExpCnlpS9HJ/Ai9Kok49PbqVznyNaWKI 1pnrvrQwVkgd2ATRft7TG7OPAUxBodjcnoearRJxT198/MW1Bfic8/SOHuvvYLa6gxFG CoWa281ecnA2gGl8QrCjNDOCFCaSIdiHbzEfTwA70Fo8BMnt1VLlM0KrUCvMP4lEp+TU Tfs5NLxV3bUNuWNGiNaW1vlvE3WgxOy+kRB9Oy88jpMUoGtKe4XeuUhMRpQ4BFxCod2J P4XPtMlTeaQb+3eWuqXzrv11f27Wf+UL06/JqOCAesfaeEIBba6x4ibJHsfzgp0wN/kf JaJw== X-Gm-Message-State: APjAAAW+m/JpVPX6g0wEpGTasIc7Tz66Jt/rso3UOLqKsjeqOCtJNEfg OSHz0xATzG2rWmlb+fAFfbQWhdQLm1k= X-Google-Smtp-Source: APXvYqzGr8DFHDJuMqZDOX6yDWnIntg7FHgJH4hEF0H2aJqp+M/yPr9wDLTZh2W/FVLxhVAMc5QF5A== X-Received: by 2002:a05:620a:a8e:: with SMTP id v14mr6338435qkg.215.1570660883605; Wed, 09 Oct 2019 15:41:23 -0700 (PDT) Received: from [10.0.100.56] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id v12sm2059699qtb.5.2019.10.09.15.41.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 15:41:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 9 Oct 2019 18:41:22 -0400 Message-Id: References: Cc: Paul Wouters , add@ietf.org In-Reply-To: To: Jim Reid X-Mailer: iPhone Mail (17A850) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 09 Oct 2019 22:41:27 -0000 Isn=E2=80=99t there already a DHCPv6 option for split horizon DNS? ISTR bei= ng dragooned as a co-author on that one.=20 > On Oct 9, 2019, at 17:47, Jim Reid wrote: >=20 > =EF=BB=BF >=20 >> On 9 Oct 2019, at 21:24, Paul Wouters wrote: >>=20 >> It is relevant, because if we believe the only thing that is needed is >> a DHCP option, then we do not need to spin up a working group. >=20 > Well the draft charter says: >=20 > Specific initial areas of focus include but are not limited to: >=20 > - Resolver discovery and selection > - Expression of resolver policy > - Support for split-horizon DNS environments > - Mechanisms to facilitate testing of new configurations >=20 > Only the first item on that list looks is if it could somehow touch on DHC= P. And even then it might only have an impact on DHCP if the current discove= ry draft in the doh WG fails to deliver. So no, a DHCP option is not the onl= y thing that=E2=80=99s needed IMO. >=20 > I would also hope we can agree to take an objective, evidence-based approa= ch rather than one which is based on subjective matters of belief. >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Wed Oct 9 17:31: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 3C831120046 for ; Wed, 9 Oct 2019 17:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 H0qUXjbuLtGt for ; Wed, 9 Oct 2019 17:31:17 -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 01DDA120020 for ; Wed, 9 Oct 2019 17:31:17 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id 3so6223044qta.1 for ; Wed, 09 Oct 2019 17:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2s2uO8aLkuIeJhzjhyC9jZgMYn05EdZL/D8vPkfOtwU=; b=W9QCfuU/zfNqvt93P6nmmjhZg2IiyZ/R3NuyBjEDnu7bqOzP2qODdGh5qDpedaJQEA 8/m/VcxE8Bc/fvXWBB0+qfgTjR/yMDNkqQ6Hic/L+3z+vpY6Ro/YquYIYn6xtXGFWR/k Lh5lt26za2NFg4gk+Y4dc6NBd4vnCnMzLZSLYheYDo8bp8Ce2IKD6U4NEVTTCRYCFMkU MVbgPlyO7qdmPoEfHje3nEP3nU85wvOO79MZfncgadE7ho7I/ZjGfR2nx9WA1niaQxth zWb/IA6NdHSyFaY04GOLaLdckNUo1ssfMF+A6+N0qgtBFP6tAqfZYRlk5WBBcsRYsvNK GLmA== 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=2s2uO8aLkuIeJhzjhyC9jZgMYn05EdZL/D8vPkfOtwU=; b=WA2y0Gl+4mfvZZq1MrrAb3Zr2uP3gc7a7rUMr869g0fkbxEs0jxtSkzAY8ysd5K7ff JJcxrrA+R97PJUGqUQN4lXrSCxJR0DC4mTzTydfRn0pporACZUnOHBDAcqW635yueNbN zp4D0cUt1YVUjbSJE3BlOKCyEbYEv1S6vTHksATLOzaNKIEyXEjBxUGMWbn77+BsWHkl NtQS4bBHzzfxK8Rf33onKJ0wGVOF8wTucu2sdljdgB3ROZagiJSHG0VzeD3JULP/9GJs JF1vut2YoxVaVQZ125eNxm3SBSD90o34Nh/i1yJRqBAHquKeuAxPnd11A6H8xpZwYUku NVeA== X-Gm-Message-State: APjAAAUDIA7FjDpMTItHF3y3hKhkPHc4Q+Dpt9pahLQydA7GDLfAD6C2 U/+UvsczAr3olcZAz0mCieEFuzjEkqY= X-Google-Smtp-Source: APXvYqwtf51NfrgTuYJAaESsKAzyyFSOQzKLCoPL0hKkuI6Fu52RjB5+dB1O2mwg4Q2L5T1h2NbDHg== X-Received: by 2002:ac8:750d:: with SMTP id u13mr7162169qtq.127.1570667475428; Wed, 09 Oct 2019 17:31:15 -0700 (PDT) Received: from ?IPv6:2601:181:c381:a1f0:5ddb:23c1:c746:93e4? ([2601:181:c381:a1f0:5ddb:23c1:c746:93e4]) by smtp.gmail.com with ESMTPSA id v5sm2626603qtk.66.2019.10.09.17.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Oct 2019 17:31:14 -0700 (PDT) From: Suzanne Woolf Message-Id: <60EEF1D7-4D72-4972-A15B-CB981E4DDFCF@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_52A03D84-2EBB-48D4-91CA-B9F098961EE1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 9 Oct 2019 20:31:11 -0400 In-Reply-To: Cc: add@ietf.org To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 00:31:22 -0000 --Apple-Mail=_52A03D84-2EBB-48D4-91CA-B9F098961EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2019, at 10:21 AM, Richard Barnes wrote: >=20 > There is a bright line here between technology and deployment policy. = The former we have some hope of progressing on, and there are meaty = questions around how applications can discover local network = capabilities and preferences in a way that is not open to abuse like the = mechanisms we have today. On questions of the latter form, the entire = history of this list, and the meeting that preceded it demonstrate, that = there is very little hope of consensus. =20 I=E2=80=99d be more comfortable if the proposed charter said this, and = further if it distinguished between standards-track development of new = protocol, extension or fine-tuning of existing protocol, and advice on = configuration and deployment. In DNSOP, and discussion of DNS-based items in other WGs, there=E2=80=99s = a distinction between DNS protocol (e.g. defining resolver behavior or, = in this case, perhaps resolver discovery), fully backward-compatible and = optional extensions and fine-tuning like new EDNS options and RRtypes, = and implementation, configuration, or operational advice.=20 If we=E2=80=99re talking about protocol to be implemented in software, = or operational capability to be configured, for basic deployment=E2=80=94 = such as standardized resolver discovery, or an EDNS option for = interrogating a DOH server for its policy on specific aspects of query = handling=E2=80=94 it=E2=80=99s possible to come up with a concise = problem description and protocol to solve it. This kind of problem seems = like a good candidate for consensus. Operations-oriented documents can be tricky, but DNSOP has done a number = of RFCs where the purpose is to document certain behavior that=E2=80=99s = been invented and deployed entirely outside of the standards process. = Those documents can be controversial, because if the behavior is seen as = harmful by a significant subset of the community, there can be deep = divisions in the WG about whether documenting it promotes the harmful = behavior, whether the WG should propose improvements to the attributes = seen as harmful, and what operators will do with the result=E2=80=94 = that is, whether the =E2=80=9Cimproved=E2=80=9D protocol will be = implemented or deployed. But there=E2=80=99s been consensus from time to = time that documenting the choices actually available in the field=E2=80=94= including how to opt-out or avoid behavior seen as harmful=E2=80=94 is = an improvement even if the perceived harm can=E2=80=99t be eliminated. I do share the reservations about a BCP, because a BCP proposes not only = documenting the choices, but making claims about =E2=80=9Crightness=E2=80=9D= . Describing tradeoffs between these protocols, the available = configuration choices, and how they impact specific aspects of user = security seems as if it should be doable, but consensus would be = exceptionally difficult around what=E2=80=99s =E2=80=9Cbest=E2=80=9D. >=20 > The charter right now has some of both. If this charter is to go = forward, it should be refactored to focus on engineering questions, and = avoid policy questions. In particular, the BCP item needs to be struck. I think it=E2=80=99s important to be realistic here about what can be = accomplished by a group and a process primarily geared towards producing = quality technical standards. There are a lot of smart people here and a = lot of interesting perspectives on what good policy looks like, but the = IETF process may not be the best way to reach consensus on a shared = view. We can agree on, for example, a description of how, = quantitatively, DNS traffic changes when the resolver is moved from the = carrier gateway to 8.8.8.8=E2=80=94 but whether the user =E2=80=9Cshould=E2= =80=9D trust one party more than another is less likely to be agreed on = any time soon. Suzanne >=20 > On Wed, Oct 9, 2019 at 9:50 AM Eric Rescorla > wrote: >=20 > Barry, >=20 > I took a first look at your proposed ABCD charter. Thanks for > proposing something. >=20 > At a high level, I think there are some good areas for discussion > here, but they're going to get swamped by the inclusion of a bunch of > contentious topics we're not likely to get resolution on. >=20 > I think this would be much stronger if it focused entirely > on technical matters on which there is at least some agreement, > specifically: >=20 > - Signalling that the network has DoH support, who provides it, > and (potentially) what their policies are. >=20 > - Signaling that the network has some kind of filtering policy > that might make the application think twice about using > DoH. >=20 > - Something like the apple proposal that does "steering" of > traffic to the right resolver. > =20 > Note that these mechanisms should generally not tell apps what > policies they should follow when they see these signals. >=20 >=20 > These seem to be on your list below. I think we should stay away from > anything that is about specifying best current practices because as > far as I can tell all but the most trivial ones (here is how to safely > run a TLS server or something) are contested. For instance, even > retention period has very strong views on both sides. >=20 >=20 > > Together, these developments may represent > > a set of shifts depending on how the new protocols are deployed: = from > > cleartext to encrypted transports; from use of unique port numbers = for > > DNS resolution to ports that support significant other traffic = (e.g., > > HTTPS); from network operator control of DNS configuration to = control by > > clients, third-party resolvers, or others; and from the use of a = large, > > dispersed set of network operator resolvers to a smaller set of more > > centralized resolvers operated by other parties. >=20 > The word "may" is doing a lot of work here. In particular, while I > realize that this centralization argument has been repeatedly raised, > it's not really a point of consensus. Consider that in the United > States, the ISP market is dominated by a very small number of players, > with two companies, Charter and Comcast, having the vast majority of > the market > = (https://www.statista.com/statistics/217348/us-broadband-internet-susbcrib= ers-by-cable-provider/ = ) > Because residential customers generally use the ISP resolver, this > market is already highly centralized. It's true that there are a lot > of much smaller enterprise resolvers, but every major > application-level DNS rollout I have seen proposed attempts to > preserve that situation. >=20 >=20 >=20 > > This potential set of shifts raises many questions given the long = history > > and current status of DNS operational practices. Network operators = have > > historically used DNS services for a variety of purposes beyond = simple > > query resolution: to mitigate network and security threats, to = enforce > > enterprise policy, to provide parental controls and other filters, = and to > > comply with relevant laws and regulations, among others. >=20 > This list of practices would be much more accurate if it included the > resolver-level DNS practices that we are trying to mitigate using DoH, > including NXDOMAIN synthesis and collection of user browsing history > data. >=20 >=20 > > Achieving these > > objectives while providing confidentiality and tamper-resistance = will > > generally require that network operators shift to one of the = available > > encrypted transports for their resolvers and that clients include > > configuration options to select them. >=20 > This entirely misses the point, which isn't just to do a lot of = encryption > but to provide security for the user. Just having network operators > transition to secure transports while continuing their current = practices > does not address the issue. >=20 >=20 > > Specific initial areas of focus include: > >=20 > > - Resolver discovery > > - Expression of resolver policy > > - Query routing in the presence of resolver choice > > - Best Current Practices for the deployment and operation of = encrypted DNS transport >=20 > This seems like it leaves all of the contested issues firmly > in scope. I can't imagine how we're going to get consensus on > best current practices, when we can't even agree on the terms > for resolver selection. >=20 > -Ekr >=20 > On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba > wrote: > Hi, all, >=20 > The IESG has worked up a proposal for a possible working group, which > we're tentatively calling "ABCD", for "Application Behavior > Considering DNS". We can discuss the charter proposal here, and > expect to approve a working-group-forming BoF for Singapore. >=20 > I realize that the charter proposal isn't going to please everyone > (and perhaps will please no one), but it's something that, at a first > level of review, the IESG accepts and will likely want to move forward > with. >=20 > See the proposal here: > https://trac.tools.ietf.org/bof/trac/wiki/WikiStart = >=20 > I am also going to remove the moderation of this list for now. Let's > see how that goes. Please continue being calm, thoughtful, and > respectful (and thanks for having done that during the moderation > period). >=20 > Barry >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add = > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_52A03D84-2EBB-48D4-91CA-B9F098961EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 9, 2019, at 10:21 AM, Richard Barnes <rlb@ipv.sx> = wrote:

There is = a bright=20 line here between technology and deployment policy.  The former we = have=20 some hope of progressing on, and there are meaty questions around how=20 applications can discover local network capabilities and preferences in = a way that is not open to abuse like the mechanisms we have today.  = On=20 questions of the latter form, the entire history of this list, and the=20= meeting that preceded it demonstrate, that there is very little hope of=20= consensus. 

I=E2=80=99d be more comfortable if the proposed charter = said this, and further if it distinguished between standards-track = development of new protocol, extension or fine-tuning of existing = protocol, and advice on configuration and deployment.

In DNSOP, and discussion of DNS-based items in = other WGs, there=E2=80=99s a distinction between DNS protocol (e.g. = defining resolver behavior or, in this case, perhaps resolver = discovery), fully backward-compatible and optional extensions and = fine-tuning like new EDNS options and RRtypes, and implementation, = configuration, or operational advice. 

If we=E2=80=99re talking about protocol to be = implemented in software, or operational capability to be configured, for = basic deployment=E2=80=94 such as standardized resolver discovery, or an = EDNS option for interrogating a DOH server for its policy on specific = aspects of query handling=E2=80=94 it=E2=80=99s possible to come up with =  a concise problem description and protocol to solve it. This kind = of problem seems like a good candidate for consensus.

Operations-oriented documents can be tricky, but = DNSOP has done a number of RFCs where the purpose is to document certain = behavior that=E2=80=99s been invented and deployed entirely outside of = the standards process. Those documents can be controversial, because if = the behavior is seen as harmful by a significant subset of the = community, there can be deep divisions in the WG about whether = documenting it promotes the harmful behavior, whether the WG should = propose improvements to the attributes seen as harmful, and what = operators will do with the result=E2=80=94 that is, whether the = =E2=80=9Cimproved=E2=80=9D protocol will be implemented or deployed. But = there=E2=80=99s been consensus from time to time that documenting the = choices actually available in the field=E2=80=94 including how to = opt-out or avoid behavior seen as harmful=E2=80=94 is an improvement = even if the perceived harm can=E2=80=99t be eliminated.

I do share the reservations about a BCP, because a = BCP proposes not only documenting the choices, but making claims about = =E2=80=9Crightness=E2=80=9D. Describing tradeoffs between these = protocols, the available configuration choices, and how they impact = specific aspects of user security seems as if it should be doable, but = consensus would be exceptionally difficult around what=E2=80=99s = =E2=80=9Cbest=E2=80=9D.


The charter right now has some of both.  If this charter is to go forward, it should be = refactored to=20 focus on engineering questions, and avoid policy questions.  In=20 particular, the BCP item needs to be = struck.

I = think it=E2=80=99s important to be realistic here about what can be = accomplished by a group and a process primarily geared towards producing = quality technical standards. There are a lot of smart people here and a = lot of interesting perspectives on what good policy looks like, but the = IETF process may not be the best way to reach consensus on a shared = view. We can agree on, for example, a description of how, = quantitatively, DNS traffic changes when the resolver is moved from the = carrier gateway to 8.8.8.8=E2=80=94 but whether the user =E2=80=9Cshould=E2= =80=9D trust one party more than another is less likely to be agreed on = any time soon.


Suzanne


On Wed, Oct = 9, 2019 at 9:50 AM Eric Rescorla <ekr@rtfm.com> wrote:

Barry,

I took a first look at = your proposed ABCD charter. Thanks for
proposing = something.

At a high level, I think there = are some good areas for discussion
here, but they're going = to get swamped by the inclusion of a bunch of
contentious = topics we're not likely to get resolution on.

I think this would be much stronger if it focused entirely
on technical matters on which there is at least some = agreement,
specifically:

- = Signalling that the network has DoH support, who provides it,
  and (potentially) what their policies are.

- Signaling that the network has some kind of = filtering policy
  that might make the application = think twice about using
  DoH.

- Something like the apple proposal that does "steering" = of
  traffic to the right resolver.
 
Note that these mechanisms should = generally not tell apps what
policies they should follow = when they see these signals.


These seem to be on your list below. I think we should stay = away from
anything that is about specifying best current = practices because as
far as I can tell all but the most = trivial ones (here is how to safely
run a TLS server or = something) are contested. For instance, even
retention = period has very strong views on both sides.


> Together, these developments may = represent
> a set of shifts depending on how the new = protocols are deployed: from
> cleartext to encrypted = transports; from use of unique port numbers for
> DNS = resolution to ports that support significant other traffic (e.g.,
> HTTPS); from network operator control of DNS = configuration to control by
> clients, third-party = resolvers, or others; and from the use of a large,
> = dispersed set of network operator resolvers to a smaller set of more
> centralized resolvers operated by other parties.

The word "may" is doing a lot of work here. In = particular, while I
realize that this centralization = argument has been repeatedly raised,
it's not really a = point of consensus. Consider that in the United
States, = the ISP market is dominated by a very small number of players,
with two companies, Charter and Comcast, having the vast = majority of
the market
(https://www.statista.com/statistics/217348/us-broadband-interne= t-susbcribers-by-cable-provider/)
Because residential = customers generally use the ISP resolver, this
market is = already highly centralized. It's true that there are a lot
of much smaller enterprise resolvers, but every major
application-level DNS rollout I have seen proposed attempts = to
preserve that situation.


> This potential set of shifts raises many = questions given the long history
> and current status = of DNS operational practices. Network operators have
> = historically used DNS services for a variety of purposes beyond = simple
> query resolution: to mitigate network and = security threats, to enforce
> enterprise policy, to = provide parental controls and other filters, and to
> = comply with relevant laws and regulations, among others.
This list of practices would be much more accurate if it = included the
resolver-level DNS practices that we are = trying to mitigate using DoH,
including NXDOMAIN synthesis = and collection of user browsing history
data.


> Achieving these
> objectives while providing confidentiality and = tamper-resistance will
> generally require that network = operators shift to one of the available
> encrypted = transports for their resolvers and that clients include
>= configuration options to select them.

This = entirely misses the point, which isn't just to do a lot of encryption
but to provide security for the user. Just having network = operators
transition to secure transports while continuing = their current practices
does not address the issue.


> Specific initial areas of = focus include:
>
> - Resolver = discovery
> - Expression of resolver policy
> - Query routing in the presence of resolver choice
> - Best Current Practices for the deployment and = operation of encrypted DNS transport

This = seems like it leaves all of the contested issues firmly
in = scope. I can't imagine how we're going to get consensus on
best current practices, when we can't even agree on the = terms
for resolver selection.

-Ekr

On Wed, Oct = 9, 2019 at 12:39 AM Barry Leiba <barryleiba@computer.org> wrote:
Hi, all,

The IESG has worked up a proposal for a possible working group, which
we're tentatively calling "ABCD", for "Application Behavior
= Considering DNS".  We can discuss the charter proposal here, and
expect to approve a working-group-forming BoF for Singapore.

I realize that the charter proposal isn't going to please everyone
(and perhaps will please no one), but it's something that, at a first
level of review, the IESG accepts and will likely want to move = forward
with.

See the proposal here:
      https://trac.tools.ietf.org/bof/trac/wiki/WikiStart

I am also going to remove the moderation of this list for now.  = Let's
see how that goes.  Please continue being calm, thoughtful, and
respectful (and thanks for having done that during the moderation
period).

Barry

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_52A03D84-2EBB-48D4-91CA-B9F098961EE1-- From nobody Wed Oct 9 22:00: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 A21071200A4 for ; Wed, 9 Oct 2019 21:59:59 -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_HELO_NONE=0.001, 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 6LF4hOOezgzj for ; Wed, 9 Oct 2019 21:59:57 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id A797B120044 for ; Wed, 9 Oct 2019 21:59:57 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 273F45F42B10; Thu, 10 Oct 2019 06:59:56 +0200 (CEST) Received: from [172.19.152.133] (p4FC210FD.dip0.t-ipconnect.de [79.194.16.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 4DD2A5F405FA; Thu, 10 Oct 2019 06:59:54 +0200 (CEST) From: "Ralf Weber" To: "Eric Rescorla" Cc: chris.box@bt.com, "ADD Mailing list" Date: Thu, 10 Oct 2019 06:59:53 +0200 X-Mailer: MailMate (1.13r5655) Message-ID: <31704184-7633-4BD4-8E8F-59B989131A78@fl1ger.de> In-Reply-To: References: <1D2F035B-A34D-42E8-BBED-8DB962B04BE1@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 05:00:00 -0000 Moin! On 9 Oct 2019, at 18:10, Eric Rescorla wrote: > I'm not quite sure what you're looking for here, but Firefox does > allow you > to > select your search provider both globally and on a per-search basis. > The > former > is done via Preferences > Search. The latter is done by having a list > of > search providers at the bottom of the suggestions offered by the > AwesomeBar, > and you can click to send the searches there. Note that you'll need to > turn > off Search Suggestions because that's implemented by sending your > partial > queries to the selected search provider. This is also done in > Preferences > > Search. And that exactly is the problem. You have to know that and set that. All ISPs NXDomain redirection I’ve encountered so far had an opt out functionality, which is exactly what you described here for Firefox. However a fresh install of Firefox is sending searches to Google directly. So if I mistype something in the browser bar it is sending this to Google for search. It does this without asking me if I would like to send data to Google or giving me a selection first. So long -Ralf —-- Ralf Weber From nobody Wed Oct 9 22:30: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 5416B120043 for ; Wed, 9 Oct 2019 22:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=elandsys.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 d9kBnjRFQ2DK for ; Wed, 9 Oct 2019 22:30:35 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id D93DB120044 for ; Wed, 9 Oct 2019 22:30:35 -0700 (PDT) Received: from sm-THINK.elandsys.com ([102.115.166.197]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id x9A5TrOj004879 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Oct 2019 22:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1570685430; x=1570771830; i=@elandsys.com; bh=kOIobD6K2HNnZYcbZKF7IYKcXI0TxHShSZRokP69+kw=; h=Date:To:From:Subject:In-Reply-To:References; b=cFPsRCxzifeGwXDcU4InNu3E6XA8eOYniDDHgmMukb3lnzA0RNezSvmVdGlj78gaO dQkG8l11B4vYYWNUrIYpHQAifhDdRNyJEOYjxC6noddImQ4Hcl+hO2SpXGKTK3z4Ed 7Yzd7cDzeW9JftgJ7jAcpslx5ihBCqTqj4X/aKhY= Message-Id: <6.2.5.6.2.20191009195808.08165628@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 09 Oct 2019 20:46:25 -0700 To: Barry Leiba , add@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 05:30:37 -0000 Hi Barry, At 12:38 AM 10/9/2019, Barry Leiba wrote: >The IESG has worked up a proposal for a possible working group, which >we're tentatively calling "ABCD", for "Application Behavior >Considering DNS". We can discuss the charter proposal here, and >expect to approve a working-group-forming BoF for Singapore. The topic looks like it is about (re)defining how DNS works. The draft charter is quite broad. I could not figure out what would be in scope and what would be out of scope. That could be clarified as part of WG chartering. My reading of the DPRIVE WG charter is that the WG was chartered to address concerns surrounding RFC 7258. That is also a specific area of focus of this BOF proposal. I suggest clarifying that (please see my previous comment about scope). The area of focus mentions DNS transport including recommendations on detail protocol usage. Does that mean the the group will make recommendations about when to use DNS over TLS and when to use DNS over TLS? Regards, S. Moonesamy From nobody Wed Oct 9 23:20: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 96B751200DB for ; Wed, 9 Oct 2019 23:20:51 -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=ejOJNlOB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZIbmoDwd 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 9BJKjPRSaFSE for ; Wed, 9 Oct 2019 23:20:49 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FBE12001A for ; Wed, 9 Oct 2019 23:20:49 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 510C121D75 for ; Thu, 10 Oct 2019 02:20:48 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 10 Oct 2019 02:20:48 -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=fm3; bh=xZUVA5c4ZZzOYrDaoR6AoS4ennhfGgl UMPgRWZfmT/U=; b=ejOJNlOB2/4nGBeHeZG+wvGw50cS05CiWg6qpXBvr9Lq2PV JRxB1hKetY+k6j0PE3hrUn5xg9HLHy8pxWu52DjXAYS38tOSDesDSIwAGxosJqP3 kgPaK0O9ZDxAExor/COXiIDPLswi/lJEqN/aaYYLspSIHGGfn/n2soGT7PvbtRfh GwrJJKWboFiNxnNXWvTsaSnHTJK5SAE4lHNgNVwwiO1LU4g77yO2aqkAB3euZ5R2 b3TE1Tw4y17w2U908Tc6jwmd4nJFBaYBhdVLyDkJbe5hilGa1y6x+7A4Z2sELqkl FKlInwr8IhKQT2S9jDFpFr887JCgOnCKuntKGIA== 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=fm1; bh=xZUVA5 c4ZZzOYrDaoR6AoS4ennhfGglUMPgRWZfmT/U=; b=ZIbmoDwdG5zb+qNmeHj5v8 vxyVgghSClozWQTh1rN9/lirGkq2BeEDrT83xz72W7+CpLTQIiBfIgbnxEfmsS26 J0daGhx9DYCGN8B1aEm6/jtFS+3mlwmPQDNdpbRJ1c4Kj5fXwRFHC91q7O/beL/9 rMgvTjecjOa4YyF2p1+ruxlf51sp9nJyzzjBkbArR/Qc1+Y339/md48+0E7RLcf3 uhQNU83jmufRT/cvqKsi1wjokXUwtibWP3QwethtPCGYXi1fS4Cn/NrfwilANuwQ LBtreqJ+yN9OhG2hwXSVZjQaN5DDSpkhQB56r8lusypyx9rjflMrb2D0t+75oeKg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E5FE0E00A5; Thu, 10 Oct 2019 02:20:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <75d9d886-32bc-4975-b5e0-16a9014e1068@www.fastmail.com> In-Reply-To: References: Date: Thu, 10 Oct 2019 17:20:28 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 06:20:52 -0000 On Wed, Oct 9, 2019, at 18:38, Barry Leiba wrote: > See the proposal here: > https://trac.tools.ietf.org/bof/trac/wiki/WikiStart Hi Barry, I think that I agree with others about trying to find a narrower and more concrete scope. The IAB have been discussing workshops on the general subject area and it initially struck me that this is a pretty credible workshop description. There are a few pieces that seem to explicitly invite the sorts of discussions of policy we've seen on this thread in the past 23 hours. Alissa's version is a lot closer to the mark, though it shares some of the woolly framing and scope issues. If we were to BoF that, I suspect we wouldn't even be able to resolve the P3P piece adequately. Just as a disclaimer, I have been on vacation and there are 36 unread threads in my IAB folder, so I'm probably behind the times a little. Cheers, Martin From nobody Wed Oct 9 23:33: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 45AB71200DB for ; Wed, 9 Oct 2019 23:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 duvNO8TInmIp for ; Wed, 9 Oct 2019 23:33:35 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 B4C3512001A for ; Wed, 9 Oct 2019 23:33:35 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q1so11277548ion.1 for ; Wed, 09 Oct 2019 23:33: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=Y+XIGDSdJ7nNV1XwkUDvPnKo5YUNdWwkkpWXkxq6WeQ=; b=rF9HjqtAj/BJGBQGOxFn37sE8u+DBm6wOp5FO1QCyAnRgOJEhwdtB/1B/ypMmFU3xD phoN3ehpfXjjWHPo1i5SWn8YAQdXI+9DTASqqUtG+GiSBrBxZgoBAwgJ4y/eUunrXt2V Eyu2LfVOh+jkGjkyteHfvQnztaz8xFxRzfH1A+08X+2ag9g6agxQzjiy5U7jmWqzNRmy 66nJ6zFNPhXfut5hsa0gxQEitUgnwjAofnntoeepuhuW6e93DduYoQbqe3COgy4uEYJc MJZ3b+EkpPXOmDYhfWpLE7a2OD9GhwuBqxphweplVK+WUBFQNmexnBKvLgoNk4Zdu+zs vbWQ== 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=Y+XIGDSdJ7nNV1XwkUDvPnKo5YUNdWwkkpWXkxq6WeQ=; b=RAP/PKJJMyU3CetTEeNCd26saIUpM4xCcqfTsjpvPB8ZCiuD9cZyCSq8iEvPF2p6Sy 2FsOBsEOlOCuavA/79II6AsgdzPpLcgI5bji/wTDkY3S6aWzdLH6AySJCNXtqtVhmgjh x4VqX5oOawSLhJ6caL4Fje2+MTsjCEWe8tI9XQ2Vd08FYHtU5LWbxi97x2HdfWu7WPzs WgfSNy2BppuK7ophg/jmI10Y/eG/WUvLgQz1Y4WFwh/zsWNoVdn8OrcOMeZc6NDcqs0S PlJnVW7ULa3kfvdlmZ8n4eai1rEq1lksDoP3/TXKcKeJ9ZUjbT0QNLt37+Q6l+Uj30LQ /Sgw== X-Gm-Message-State: APjAAAWqXJcv7k9J8hDtZPi8U9zhOMBnNRDDrjk9Y7SB5CVs2jzlz0Fr /auhePbpRD0cabiP3UEQJwzBZWy1X6jAcM8oKrU= X-Google-Smtp-Source: APXvYqxBJLvPlC5ktwqdQZ/9kwMkLduejVluXcsvYGc5DF9X3ZqF9Zh8yXLGz/y6JcR9JkmSBvr/8QSDaEB0BPHVC0k= X-Received: by 2002:a6b:f40f:: with SMTP id i15mr8450448iog.54.1570689214977; Wed, 09 Oct 2019 23:33:34 -0700 (PDT) MIME-Version: 1.0 References: <72E87905-63B1-45C3-8F1A-921E7B753E68@cisco.com> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 13:33:23 +0700 Message-ID: To: Barry Leiba Cc: "Eric Vyncke (evyncke)" , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b61cc505948894cf" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 06:33:37 -0000 --000000000000b61cc505948894cf Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 9:13 PM Barry Leiba wrote: > > Why not just put your names on the form? > > Working on it; we're in the middle of a meeting right now, but I will > fix it after. > Hi, I see that the description has been updated. It looks like the proponents are 4 ADs (rather than "5-6"), and one long-time IETF member who has been on the IESG in the past. Is that correct? thanks, Rob --000000000000b61cc505948894cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000b61cc505948894cf-- From nobody Thu Oct 10 00:17: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 8130E120044 for ; Thu, 10 Oct 2019 00:17:46 -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=cooperw.in header.b=ROX3+GCT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PVCj65OQ 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 cw_N6YtPErFR for ; Thu, 10 Oct 2019 00:17:45 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091A0120033 for ; Thu, 10 Oct 2019 00:17:45 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 40CF040D; Thu, 10 Oct 2019 03:17:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 10 Oct 2019 03:17:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=a 8D8vN41tNDxI2AtWoLIngBg3fbXYxdJL/apNSZJ464=; b=ROX3+GCTO5nEi/1Rk q6zXyb2GkKMIP1g46ls3egxCuUhXuMCG6pxSFmjJjfL3qeMUyYW+cjYXg0ZAariJ eP58Xg5B7G2xHE4sacuagTFrr2WiAi6efrIRViJhZhU4X2E8xw+ViMV9/phLz9ms 6qktXDIfXe1D6/YUTIX7bSkxoyaSUiZVy0RghhQY2W8GiJ9EGVD/qLq9lx3PhcIO FAiHlDtR//C8HH3tm18B9sGkDz+I8vclWjdF029zBxQ3AoruiG+Y8+yAMiXMCAsI xAW+PLAEGAK+hoVlgPicZ9EZOMSkhsUqy+ogC6DeoluSar9S0a3+ECfttCf1iHA1 j5FGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=a8D8vN41tNDxI2AtWoLIngBg3fbXYxdJL/apNSZJ4 64=; b=PVCj65OQkIbc5L0iiW2XMxTYLIQrTWvuC9dQ3KpeCv3JOwB2jvnFSg+Id PIXm9+ftGWj/2xIj/bfdu3L5y0jf9CI4PkK3FWQnArec69HgPfd3zz19e045D/hi l+JATC+wbDA3cpk7aUIZ1/9O015Yt6dvy0ovPG6X/rHAvKM1aIhVkvM4c9Pe45fK QVT7MiJd1+zjnxMzYNl73pXJfyQcXfTaS7IvN6NEwB9WySN6ZquInvxlI9WN6VvZ 1d/4WaQcVSygiVIZ93cYrKZZ+Ycq33tJp0EBXE6nklGWqplRXrUXB4E1lP1KHR99 Tpl+/BAHkOJOwVdQ1dYjRnYJVXwMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedvudejrddugeelrddufeehrddujeehnecurfgr rhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [172.35.0.75] (unknown [217.149.135.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 0578BD60063; Thu, 10 Oct 2019 03:17:42 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Thu, 10 Oct 2019 09:17:41 +0200 Cc: Paul Wouters , add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <92EE71EA-48B5-4292-A290-80D7A9F9BFA8@cooperw.in> References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> To: Jim Reid X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 07:17:46 -0000 Hi Jim, > On Oct 9, 2019, at 11:46 PM, Jim Reid wrote: >=20 >=20 >=20 >> On 9 Oct 2019, at 21:24, Paul Wouters wrote: >>=20 >> It is relevant, because if we believe the only thing that is needed = is >> a DHCP option, then we do not need to spin up a working group. >=20 > Well the draft charter says: >=20 > Specific initial areas of focus include but are not limited to: >=20 > - Resolver discovery and selection > - Expression of resolver policy > - Support for split-horizon DNS environments > - Mechanisms to facilitate testing of new configurations This was actually in some draft text I originally generated that led to = the version Barry eventually shared with the list, but this text itself = doesn=E2=80=99t exist in the version that appears at = .=20 Alissa >=20 > Only the first item on that list looks is if it could somehow touch on = DHCP. And even then it might only have an impact on DHCP if the current = discovery draft in the doh WG fails to deliver. So no, a DHCP option is = not the only thing that=E2=80=99s needed IMO. >=20 > I would also hope we can agree to take an objective, evidence-based = approach rather than one which is based on subjective matters of belief. >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Thu Oct 10 04:42: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 99CC6120C1D for ; Thu, 10 Oct 2019 04:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaof-7CXtDC5 for ; Thu, 10 Oct 2019 04:42:05 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E448120C0A for ; Thu, 10 Oct 2019 04:42:05 -0700 (PDT) Received: from dooku.sandelman.ca (business-178-015-097-209.static.arcor-ip.net [178.15.97.209]) by relay.sandelman.ca (Postfix) with ESMTPS id 9C6EB1F456; Thu, 10 Oct 2019 11:42:03 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id DE0B0346B; Thu, 10 Oct 2019 13:42:51 +0200 (CEST) From: Michael Richardson To: Barry Leiba , add@ietf.org In-reply-to: References: Comments: In-reply-to Barry Leiba message dated "Wed, 09 Oct 2019 09:38:37 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 10 Oct 2019 13:42:51 +0200 Message-ID: <4050.1570707771@dooku.sandelman.ca> Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 11:42:08 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Barry Leiba wrote: > The IESG has worked up a proposal for a possible working group, which > we're tentatively calling "ABCD", for "Application Behavior Consideri= ng > DNS". We can discuss the charter proposal here, and expect to approve > a working-group-forming BoF for Singapore. > I realize that the charter proposal isn't going to please everyone (a= nd > perhaps will please no one), but it's something that, at a first level > of review, the IESG accepts and will likely want to move forward with. Let me reply here before having read the thread. My impression is that ABCD will act as an architecture group for the problem with DNSOP (OPS Area), DPRIVE (INT Area), and DOH (ART area) providing specific technologies. It seems that many of the discovery/configuration protocols which are appearing in DPRIVE from Tiru/Dan/me, and Tommy and Thomas would fit into ABCD rather than DPRIVE. Please confirm that this is your intention? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2fGTsACgkQlUzhVv38 QpAjTgf/WN0qHuM83m4K0/OGSBegDCSQOfKax1XNmBq414I7lUBuEF2JuRU6MdYt AeNIr26s++WmxGTfk0A57J3kpbX2+1H6YOpsSFjOub+spmQxZJQ867wCcmwvRWt6 7qXP76s0mAE9EJIinWJLuxQ6rRi8UFiqSonxMymLTB9SR3q/UnBoAupq3allFQPE m+rSewje24SkMWXRebOxyND+Dc0fZ/hu6sZu2E55wDPw/t17Y8ZnTkAgVYmUqyVb Y3UmVjwClR0/KreXJIS3TgQMdeFGUiSEfU7p459mToLT75pHKyH4EPDFJmBoiHpm ualgLem7qsve4S5SoJ4nhkkqb2E1Jw== =Xqaa -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 10 04:43: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 99AE1120C1D for ; Thu, 10 Oct 2019 04:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZsWneGIU-_R for ; Thu, 10 Oct 2019 04:43:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF7C120C0A for ; Thu, 10 Oct 2019 04:43:38 -0700 (PDT) Received: from dooku.sandelman.ca (business-178-015-097-209.static.arcor-ip.net [178.15.97.209]) by relay.sandelman.ca (Postfix) with ESMTPS id A7EDC1F456; Thu, 10 Oct 2019 11:43:37 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2162E346B; Thu, 10 Oct 2019 13:44:26 +0200 (CEST) From: Michael Richardson To: Jim Reid , add@ietf.org In-reply-to: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.com> References: <67CDBD8A-9726-430A-BE9B-B556A2633B1B@rfc1035.com> Comments: In-reply-to Jim Reid message dated "Wed, 09 Oct 2019 09:41:29 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 10 Oct 2019 13:44:26 +0200 Message-ID: <4142.1570707866@dooku.sandelman.ca> Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 11:43:41 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jim Reid wrote: > One meta-question: would ABCD be in the art area? I think ops might be > a better home for it. +1. Please also consider that we need strong connections to Enterprise operator= s, or we fail. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2fGZkACgkQlUzhVv38 QpDyKAgAlMeBWI2iyl4COv7aNz7zqYwIpBrcKHMEpbf/v5PAKWX5QeNZY3QZCkZs RKMLBoaWYoxnasSV43Krojzssp8ElPD3+kmY6TsG7HzVXvI2Ur3ScwO1ykOezGsj Qn93JilsMbmNFScIi6BeiQid4MoL/f9ZeljJZWf+tKsSuJVE8K/Xyz9fXYaaL3p8 jbYo5XiuaUazwfNfaALBNK3zfsQUKzoyEype+ffl8bMUG8cL7bWwJ/AMbK7C89FV fVMzRzuVXnCDOCFjX2ME8rybhNeOS3OuQ5Bx8pWb6syHiA5Jm2qPBTnDLFLm9RFD P4/St7nWKSRuiiVSaYCsVSSMQy4klw== =1JZe -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 10 04:46: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 2BB57120C0E for ; Thu, 10 Oct 2019 04:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Edp7PeOVDCgd for ; Thu, 10 Oct 2019 04:46:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF19120C0A for ; Thu, 10 Oct 2019 04:46:18 -0700 (PDT) Received: from dooku.sandelman.ca (business-178-015-097-209.static.arcor-ip.net [178.15.97.209]) by relay.sandelman.ca (Postfix) with ESMTPS id DE4411F47F for ; Thu, 10 Oct 2019 11:46:16 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4D565346B; Thu, 10 Oct 2019 13:47:05 +0200 (CEST) From: Michael Richardson To: add@ietf.org In-reply-to: <7B345BCE-F23A-47F7-95EB-2201F57F84E7@fugue.com> References: <7B345BCE-F23A-47F7-95EB-2201F57F84E7@fugue.com> Comments: In-reply-to Ted Lemon message dated "Wed, 09 Oct 2019 10:16:59 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Oct 2019 13:47:05 +0200 Message-ID: <4265.1570708025@dooku.sandelman.ca> Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 11:46:20 -0000 Ted Lemon wrote: > If the proposal was half baked due to hurry, maybe the right approach > is to wait until March. If you really think it=E2=80=99s urgent, you = could do > it as a virtual BoF in January. That=E2=80=99s what the IESG would s= ay to me > if I proposed something that was too rushed. I think that we need to have the WG-forming BOF at 106, so that in March (w= hich will be better attended) we can actually hit the ground running with a WG. Most of the WG charter arguments are going to happen on the list. --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 From nobody Thu Oct 10 04:47: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 CB9A1120C0E for ; Thu, 10 Oct 2019 04:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 PQZXn68qAJn0 for ; Thu, 10 Oct 2019 04:47:17 -0700 (PDT) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 63B91120C0A for ; Thu, 10 Oct 2019 04:47:17 -0700 (PDT) Received: by mail-io1-f50.google.com with SMTP id u8so12937493iom.5 for ; Thu, 10 Oct 2019 04:47:17 -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=irZlH3nH1KT7AyprA78Ocwua0PmG1cpq0jSfyAKgN0Y=; b=QlkmbwxKsauohJ5G9fC/k7vYFJ/V0kYiSahMAQTVv5WjBzER/6fvt3fAHEu2WGqlwq zzegNFgtEY0O/7gUfTF6qSJiyBo/htyCaPd7BalGycSCaeeFnUFBhCXgFBGxqw3isT3e 95J0GBOuxnQyAFhBDuHnevPF/rFzMCr+/56197IQG4p1Ki49i9RHVyXVb2i8mRSg2G57 gJmw53eJZe45+WfmnKiuoB8ejd48AAFRChnjHSYmdhHPdbUoGAZ50aKBHNKLvb3jouh0 QX7WMKTiN2/F0fEuo2DdsZyXqtsmEp3IW7xJvM7WU60j5/OyGEXdLDLV12qSzd8rgPGn 4EhQ== X-Gm-Message-State: APjAAAWNPVlGeOfZGh2AfVEqVMUcfYG/Au6n5p9kg6CwQZWhIvMngtKw fXSxaZoOhY5zLnb4JoCdiLLb5Fvhm+c/fEPJBk9mJtVj X-Google-Smtp-Source: APXvYqxxCC9/n4G98E8c2U9xRUlOEUH3kWCr6SEo/BfXfM0bD4gBPXdZrshUxvi3R0anvxqGPPNVWBkYjGA/TNmBafY= X-Received: by 2002:a5d:8905:: with SMTP id b5mr9789088ion.187.1570708036331; Thu, 10 Oct 2019 04:47:16 -0700 (PDT) MIME-Version: 1.0 References: <4050.1570707771@dooku.sandelman.ca> In-Reply-To: <4050.1570707771@dooku.sandelman.ca> From: Barry Leiba Date: Thu, 10 Oct 2019 13:47:04 +0200 Message-ID: To: Michael Richardson Cc: ADD Mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 11:47:19 -0000 The intention is to put work items into an appropriate working group, also considering the other work the relevant working groups are doing. That means that we'd have to look at where this (ABCD) charter ends up, whether we do or don't decide to recharter DPRIVE to tweak anything (we don't currently plan to, but it might turn out to be helpful), and how much workload there is here and there. So, yes, it's possible that things that might look like they fit into DPRIVE now would be better done in ABCD. We'll have to make that decision after we see the final charter. Barry On Thu, Oct 10, 2019 at 1:42 PM Michael Richardson wrote: > > > Barry Leiba wrote: > > The IESG has worked up a proposal for a possible working group, which > > we're tentatively calling "ABCD", for "Application Behavior Considering > > DNS". We can discuss the charter proposal here, and expect to approve > > a working-group-forming BoF for Singapore. > > > I realize that the charter proposal isn't going to please everyone (and > > perhaps will please no one), but it's something that, at a first level > > of review, the IESG accepts and will likely want to move forward with. > > Let me reply here before having read the thread. > > My impression is that ABCD will act as an architecture group for the problem > with DNSOP (OPS Area), DPRIVE (INT Area), and DOH (ART area) providing > specific technologies. > > It seems that many of the discovery/configuration protocols which are > appearing in DPRIVE from Tiru/Dan/me, and Tommy and Thomas would fit into > ABCD rather than DPRIVE. > > Please confirm that this is your intention? > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From nobody Thu Oct 10 05:08: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 4E47B120C57 for ; Thu, 10 Oct 2019 05:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 e6_R9x3QMF6w for ; Thu, 10 Oct 2019 05:08:41 -0700 (PDT) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.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 AE771120C34 for ; Thu, 10 Oct 2019 05:08:41 -0700 (PDT) Received: by mail-io1-f46.google.com with SMTP id q1so13133225ion.1 for ; Thu, 10 Oct 2019 05:08:41 -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; bh=VnrcaPI2sg4PuuJ2Rrh7Tunpy0hygD50RgajMPiFB3I=; b=uejTakC4sPjezqV2pl0E6m0GB9OeSoaxcqR6gxzyi62/3aJRGEkzenqA2Lw+V9nvQM pdQtc33ZbS7qZ8ZbiN7jDBPFcfJ3/GaWtvp3/eUtnO/rBsEpLPy9J9lmSCslGz0XMKt6 4oA0R6Sm/b5ON+owKr1l1JIbBSivrqAn0x/FJDuJC0sSTOa2Ni0CCAMZEryFyELcLZXO 5o7o4/w3hPB1NcUiH6VRNLlAYt1aN+n/Xv9DdiBZsZiQBPctx419VEBTKgCb5sPvDHMg L7UtBchc+ko2D7WA9MPjyAIhtnyqeEV70hqdlbyGsWlU0IDEJyxdRidnMlY2cWaiLjiR MRkA== X-Gm-Message-State: APjAAAWcYhRcS0rj4l2vBwNc+2laUjplNGICbTLzIoCSfKCHHPmU4luz 7aimYtpAgacFw0QxBpRKyhWpqIkZekNmyVsNUef5mN3F X-Google-Smtp-Source: APXvYqzyVn5gagbNtwcz7Yo1h6t3p7I6JwxI+kAT/K+w0cXYpu/iZ7anbV5zk2w15N6Mfy88OCuZz70NaPmH6VhEU9A= X-Received: by 2002:a92:490f:: with SMTP id w15mr379680ila.187.1570709320462; Thu, 10 Oct 2019 05:08:40 -0700 (PDT) MIME-Version: 1.0 References: <4050.1570707771@dooku.sandelman.ca> In-Reply-To: From: Barry Leiba Date: Thu, 10 Oct 2019 14:08:29 +0200 Message-ID: To: ADD Mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 12:08:43 -0000 Further following up on the more general thing (a BoF and charter proposal): I'll stress that what's out there in the BoF wiki is a proposed starting point -- it represents the IESG's trying to be helpful in getting concrete charter discussion started. It's not a finished charter that's being lobbed at the community, and we *want* you to discuss it and refine it, to throw parts of it away and add other things that you need. Please *do* start that discussion -- we'll discuss it at the BoF, but we should wait until the BoF to work on it. Have at it. For that matter, even having a BoF in Singapore isn't set in stone: if you, the community, think we've erred in assuming that a BoF now is the best approach, and we get rough consensus on that, we can easily cancel the BoF between now and then. This really *is* out to the community for discussion and consensus. Let's figure out, together, what the best way is to make progress on useful documentation here. Barry On Thu, Oct 10, 2019 at 1:47 PM Barry Leiba wrote: > > The intention is to put work items into an appropriate working group, > also considering the other work the relevant working groups are doing. > That means that we'd have to look at where this (ABCD) charter ends > up, whether we do or don't decide to recharter DPRIVE to tweak > anything (we don't currently plan to, but it might turn out to be > helpful), and how much workload there is here and there. > > So, yes, it's possible that things that might look like they fit into > DPRIVE now would be better done in ABCD. We'll have to make that > decision after we see the final charter. > > Barry > > On Thu, Oct 10, 2019 at 1:42 PM Michael Richardson > wrote: > > > > > > Barry Leiba wrote: > > > The IESG has worked up a proposal for a possible working group, which > > > we're tentatively calling "ABCD", for "Application Behavior Considering > > > DNS". We can discuss the charter proposal here, and expect to approve > > > a working-group-forming BoF for Singapore. > > > > > I realize that the charter proposal isn't going to please everyone (and > > > perhaps will please no one), but it's something that, at a first level > > > of review, the IESG accepts and will likely want to move forward with. > > > > Let me reply here before having read the thread. > > > > My impression is that ABCD will act as an architecture group for the problem > > with DNSOP (OPS Area), DPRIVE (INT Area), and DOH (ART area) providing > > specific technologies. > > > > It seems that many of the discovery/configuration protocols which are > > appearing in DPRIVE from Tiru/Dan/me, and Tommy and Thomas would fit into > > ABCD rather than DPRIVE. > > > > Please confirm that this is your intention? > > > > -- > > ] Never tell me the odds! | ipv6 mesh networks [ > > ] Michael Richardson, Sandelman Software Works | network architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > From nobody Thu Oct 10 05:51: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 E4DE912006E for ; Thu, 10 Oct 2019 05:51:32 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 cMxDEzPS8Fqm for ; Thu, 10 Oct 2019 05:51: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 23203120018 for ; Thu, 10 Oct 2019 05:51: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 D66CA6A266; Thu, 10 Oct 2019 14:51:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1570711887; bh=NmDAEAak61m8/nXUE91a9jj5BRGCMSJwEqut//SEfV0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=Lth1y38b/DsXzJulcC6j2RwWgouxKTCARdfT94JZKgc7t2SPkbDXqavqpxWTcu4vd ZyIHNXXnU93XGBduOeATliIw9kpxJWjBvIlBZ40THj9IVPfn9YYyq616AeIt8JIMO9 qpKbly70ZojXphKQRJ3BSWN3nvmnoJfVBw9ibEJvfAScxXbi2AVDB0EWZE0o5sbz0e xEAWjhtUyLE9xmSfH2IfpCG6dWKRA0ScPEvoHlEtIvNuzadrav4Kzawd3bvlVO1hSH 9k4aBB70NWvpUqazWLWaO9p7jdG6eAUzvb3GXuWAPJq7qNyRivqY3lvNh6xTCdxP88 mo07SidfUdplA== 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 C98123C00A5; Thu, 10 Oct 2019 14:51:27 +0200 (CEST) Date: Thu, 10 Oct 2019 14:51:27 +0200 (CEST) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Paul Wouters Cc: ADD Mailing list Message-ID: <855223006.31674.1570711887732@appsuite-gw2.open-xchange.com> In-Reply-To: References: <7ABDABF3-2AE4-405D-9B14-407B88D33025@senki.org> <9B8A4652-7F2B-428D-A43C-807E6109F464@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request 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, 10 Oct 2019 12:51:33 -0000 > Il 9 ottobre 2019 22:06 Paul Wouters ha scritto: >=20 > On Wed, 9 Oct 2019, Barry Greene wrote: >=20 > > The problem I=E2=80=99m having with this whole discussion is the small = group pushing for the community to =E2=80=9Cthrow away > > the screwdriver from my toolbox =E2=80=A6 a hammer is just as effective= to hammer in screws.=E2=80=9D Battling the miscreant > > threat should be expanding the security toolbox, not limiting it.=C2=A0 >=20 > It's not a "tool" that is taken away from you. It's a leaking water > pipe. And you are arguing that you cannot see if the water is contaminate= d > anymore because the pipe got fixed. I don't think anyone has a problem with fixing the leaks from the pipe. The= problem is that the plumber that showed up to fix the pipe is also adding = another stretch of pipe to divert the water into someone else's tank. --=20 =20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com=20 Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Oct 10 07:26: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 48274120013 for ; Thu, 10 Oct 2019 07:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 fO4UxCODUj7e for ; Thu, 10 Oct 2019 07:26:29 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE0B120018 for ; Thu, 10 Oct 2019 07:26:29 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id BB18F2420FDE; Thu, 10 Oct 2019 14:26:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <92EE71EA-48B5-4292-A290-80D7A9F9BFA8@cooperw.in> Date: Thu, 10 Oct 2019 15:26:25 +0100 Cc: Paul Wouters , add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> <92EE71EA-48B5-4292-A290-80D7A9F9BFA8@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 14:26:30 -0000 > On 10 Oct 2019, at 08:17, Alissa Cooper wrote: >=20 > This was actually in some draft text I originally generated that led = to the version Barry eventually shared with the list, but this text = itself doesn=E2=80=99t exist in the version that appears at = Whoops! My mistake Alissa - thanks. From nobody Thu Oct 10 07:29: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 AC631120122 for ; Thu, 10 Oct 2019 07:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=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 Wpzdcu1BsxrF for ; Thu, 10 Oct 2019 07:29:23 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F0A1200E7 for ; Thu, 10 Oct 2019 07:29:23 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 9333F2420FDE; Thu, 10 Oct 2019 14:29:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Thu, 10 Oct 2019 15:29:21 +0100 Cc: Paul Wouters , add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <005A6F1A-D44D-4184-80AC-8E9A280E33E1@rfc1035.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 14:29:25 -0000 > On 9 Oct 2019, at 23:41, Ted Lemon wrote: >=20 > Isn=E2=80=99t there already a DHCPv6 option for split horizon DNS? I wasn=E2=80=99t aware of that Ted - thanks. Even so, that option doesn=E2=80=99t detract from the point I was trying = to make: all the stuff in the proposed charter can=E2=80=99t = realistically be accommodated in a DHCP option (or more than one = option). From nobody Thu Oct 10 07:48: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 0C72E1200B1 for ; Thu, 10 Oct 2019 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 OLiX0-BxA7Zr for ; Thu, 10 Oct 2019 07:48:14 -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 F18E712002E for ; Thu, 10 Oct 2019 07:48:13 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id q1so14355522ion.1 for ; Thu, 10 Oct 2019 07:48:13 -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=c1mNho29FmI5E82fVx24gQu0zecp9uYUhNqUn7WSJgM=; b=sPWppXqUuQRPzQTt+BZ5biJC85bdA6hxexLrJWQBbljRnBbcqziNr84BW8++qbO/P0 DdOCezkBH+pErb9jZeXe/0zaC+H635XWjAupCUuY87Qj4jV9AUn4nImGaSRoSOLMBGDi cZphbXNA/i01nAwNe+lf31drBc/kULtZS0+CLhuakoSedAqvp1e9RqtDwofrjX10SQAc cfi84ntBoHD3Oqt6tpniWXbSItGWLXBaJXH5mXthrJUZtZvOQYw8jdhE6tH7h45IpraO sFN5RqdKfQtfIhjcfpC+AasobZTXLeZ/lRT27ehnCMoWYucYAEgIJD5I4LPB6aOxIE8l 2vmQ== 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=c1mNho29FmI5E82fVx24gQu0zecp9uYUhNqUn7WSJgM=; b=cRoQkXzNKK15MU1loZW1MkIJiwhwK4vCGadurlmB6p+aVyjm3rnDgI/C1RVMe7hSY7 H5PLe/X0idYfuugPeu+53oNG8tqAFiX6LPYLVK6jvNc9cu0mbVkVR2k7fTb0XnVoHNey fQyqO9EkKcB8WHr6MyI8/AjfPhH8XNzM31uDQcolATSNC75RvXxPsTamdYzX75XFmBD1 gAMWkh7Ovo/IB8kS7PH5iK/d/AphEG7/SKK4qMiEPrLkeNk435HTQrSncrcBiGOG+Uw/ Cc7i++WFGsWimDW/1MDWaCcVqfDfCr8vc5TfTbubDsrNQo84hTSn/Mvl4TWI3kl8IRAE wwxQ== X-Gm-Message-State: APjAAAX4aN5tfsMttgxyeSixGSkWOASwJg3QEhlZsgZlmkYkHvE193Gv PekN+GXP+6HxwMrMSkkl6Pdf+Drt4XQecRzrZxA= X-Google-Smtp-Source: APXvYqzM+CVO68UU0qMErsPNj9gbB7jHtUYtUDdkZUT14GUz9IKZtXN0AVr81ZG0ajdLlDg13SD6p2+gAd6H9D2gQyU= X-Received: by 2002:a6b:e910:: with SMTP id u16mr11138296iof.196.1570718893163; Thu, 10 Oct 2019 07:48:13 -0700 (PDT) MIME-Version: 1.0 References: <4050.1570707771@dooku.sandelman.ca> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 21:48:01 +0700 Message-ID: To: Barry Leiba Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000ab4f8d05948f7d68" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 14:48:16 -0000 --000000000000ab4f8d05948f7d68 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 7:08 PM Barry Leiba wrote: > For that matter, even having a BoF in Singapore isn't set in stone: if > you, the community, think we've erred in assuming that a BoF now is > the best approach, and we get rough consensus on that, we can easily > cancel the BoF between now and then. > These two drafts seem well-intentioned: https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-00 https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-00 Why not just handle them in the DPRIVE WG? I don't think a 200-person BoF in Singapore will get a better result. thanks, Rob --000000000000ab4f8d05948f7d68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For that matter, even having a BoF in Singapore isn't set in stone: if<= br> you, the community, think we've erred in assuming that a BoF now is
the best approach, and we get rough consensus on that, we can easily
cancel the BoF between now and then.


http= s://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-00
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-00<= /div>

Why not just handle them in the=C2=A0DPRIVE WG?

I don't think a 200-person BoF in Singapore will= get a better result.

thanks,
Rob
<= /div>
--000000000000ab4f8d05948f7d68-- From nobody Thu Oct 10 08:04: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 CDF101201DE for ; Thu, 10 Oct 2019 08:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 121YEB5slYh7 for ; Thu, 10 Oct 2019 08:03:55 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 0B4E7120123 for ; Thu, 10 Oct 2019 08:03:54 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id v2so14387849iob.10 for ; Thu, 10 Oct 2019 08:03:54 -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=6I6uTq26z0mkhlOCMe/GLoiopn9euc/ZIjKtf5GwkPs=; b=bib6tN7HTn2rH7tcmMPA+7IAvkoGhTCwEiUxPAUm1Q/W6mw84g/qjZj2x9f9DnIdZW cIGXUYKMRIVnHTldnajeVynScvqwhrfszWecMP3ZT/NYJMa82rXU4VaAyHhf8jFnaGZB Vp44BQO4I6a0THl/bJOekfqHUIrbeZ0OnivQ3N6Z1xdJd+LzspsaTIsiyl5O0qZXJgIZ 2ZuzeBUsmhgP4RbhrBlgJZa9+E3QwcH4qdOj5cGh7HWQS1kxp9wZWQb6kRfeILALOVRr +EquefZaiNNF1tg9RpYiDAKr1z/hUip/Zr+yL1xCMu+RbS0qnuROsj+ZR2G5jnUEk/pi s+Ag== 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=6I6uTq26z0mkhlOCMe/GLoiopn9euc/ZIjKtf5GwkPs=; b=p7jiPMf3Ql9yNyjHA4VFGscEAyYAecGoln41DoFZvOlMPMcb2MihWR3xqyJEmC1pux KqPz8duCqgevVtcwS9Ani9JfNUa7x4nbhgx2rOuFDVYvxmVNJLCKAijXD12z6r8OCFUK V+lXq9SLqU0LkH7v98f9UwE8XbHXulB441NE00M/aFNZrZi3BuqEW5rZo/3Xa0dgBwiY g5ysWVok7PUMgbf55RGTnBjHEn7YYfDP8dfEGKM9Tn3Rgxd/8D1ROulo6E6sOiaMOaNk z3+dY6wMWYs7ly2IfJkGTCYsHix/dqUfW4q0avyfWJDb5Q22tH7PD185bFmDUiPPbPn+ 5Cww== X-Gm-Message-State: APjAAAUDwTUKpFBgohA2p+Qmo0H2wkAHngshyjLb/VNpQaxOKcO1o9Bt KTdJ6Ck7zXeF+BQYWjZhlITVsuhhVB7vcrPVO29wM8N4 X-Google-Smtp-Source: APXvYqxLZAT88rWwSco5Hylx7iVnfg9HT0GZgf85qWLw4beRNPS9ob+GfUal8CLHU2/WJx9XXjWvMr/FV/ofVFDV1T4= X-Received: by 2002:a6b:5814:: with SMTP id m20mr10833394iob.242.1570719834202; Thu, 10 Oct 2019 08:03:54 -0700 (PDT) MIME-Version: 1.0 References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> In-Reply-To: From: tirumal reddy Date: Thu, 10 Oct 2019 16:03:41 +0100 Message-ID: To: Paul Wouters Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c26c3605948fb593" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 10 Oct 2019 15:04:10 -0000 --000000000000c26c3605948fb593 Content-Type: text/plain; charset="UTF-8" On Wed, 9 Oct 2019 at 15:05, Paul Wouters wrote: > On Tue, 8 Oct 2019, tirumal reddy wrote: > > > How and how would any enforcement system work for a variety of DNS > > providers all over the world? ISPs? hotels? coffeeshops? Mobile > > providers? Will there be an industry standard org? How will this > > not devolve into government sanctioned mandatory DNS providers on > > my mobile device? > > > > Users may or may not trust the attached network and the DNS server > provided by the network (e.g, a public > > network). It is similar to the way users disable VPN in specific trusted > networks (e.g., Enterprise network) > > and VPN is enabled by default in all other networks. > > The user can already do that, without any help from the local network. > If someone configures a VPN or a DoT/DoH, they do not need the local > network for anything except passing a captive portal. I don't understand > what you are adding here. > > Trust relationships of networks are: > > 1) I don't need to trust them, so I don't > 2) I am forced to trust them, so I do. > > In the case of an enterprise network like 2) they can already > pre-install the CA certs I need to trust on connecting to the > network (see the IETF network do something similar there) > I am referring to BYOD devices, BYOD will not have Enterprise root certificate and cannot be provisioned with the Enterprise DoT/DoH server using AD. The owner of the the BYOD has a choice whether to use the Enterprise network provided DoT/DoH server or not. > > > No. If the privacy requirements of the endpoint are not met, the DNS > client can discard using the discovered > > DNS server in the attached network, and connect to a public DNS resolver > meeting the endpoint privacy > > preserving data policy requirements. > > Again, it is the other way around. Users should not need or want to > trust the local network. My laptop mostly connects to completely unknown > networks with zero trust _or_ a trusted enterprise network. What are > these networks that a user should "trust to filter or log their DNS for > them" ? > > > The proposed mechanism also helps the DNS client to automatically learn > updates to the privacy claims by a DNS > > server and avoids the need for users to periodically manually review the > privacy statement. > > Again, this is fixing a problem that I do not think exists. Why should I > trust or not trust this network with DNS to begin with? Their privacy > policy update will not change that for me. Either, they were already too > weak for me to trust, so I don't care about their DNS privacy policy > update, or I trusted them already, in which case it seems I trust them > more than my own trusted DNS - AKA I'm forced to trust them (an > enterprise network). > I disagree, user needs to know whether his privacy requirements are met by the local DNS server or public DNS server. If the public DNS server decides to change the policy to sell user data to third-parties, the user would want to move to a different DNS server. > > > The privacy policy information helps make the decision whether the DNS > provider can be trusted or not. > > No it does not. It can only tell me when I for sure cannot trust them. > Since I did not audit their logging, I can never be sure to trust them. > An end-user cannot audit the privacy claims by any DNS provider including the public DNS revolvers, and can possibility rely on the audits performed by third parties (similar to way VPN providers use third party audits). How does the user know the public DNS server has not made false privacy claims ? > > It's like saying a privacy policy will select whether I use HTTP:// or > HTTPS://. That is not the question. The question is why would I ever > use HTTP:// ? > > > I'm still not convinced this statement is wrong. And additionally > can > > see some serious harmful effects into mandatory censorship if this > kind > > of system becomes mandatory on people's devices. > > > > I disagree, the proposal helps the user to choose a DNS server that best > supports the desired privacy > > policies. > > I either have a really good DNS provider that I fully trust up my > sleeve, or I don't. If I do, I don't need the local network one. > If I don't, I have no choice but the use the local network one. > Local DNS server for several reasons, blocking malware and phishing, enforce MUD rules to only allow intended communications to and from the IoT devices. Several other reasons like "CDN endpoint selection" are listed in https://tools.ietf.org/html/draft-reid-doh-operator-00 > > > DNS clients do not need to fallback to clear text DNS, and can use the > DoT/DoH server provided by > > the local network. > > Then why should I ever take a risk that this local network has a privacy > policy that does not actually match its implementation? > Firefox falls back to clear text DNS because the local network has parental control or DNS filtering. Android has an option to automatically use to the local DoT server (opportunistic mode). > > > Further, it also provides a mechanism to securely signal to the DNS > client that the > > attached network performs DNS filtering. > > You cannot signal securely unless I have a trust anchor already on my > device that would be used. If this is a CA-type store of hundreds of > trust anchors, I cannot really trust them for this decision over a > personally selected known safe choice. You may want to re-look into the Security and Privacy considerations sections, we are not suggesting to rely on the hundreds of trusted anchors on the browser/OS. > If it is enterprise specific, > we already have mechanisms in place for securely obtaining updated DNS > mechanisms. Like via VPN using RFC 8598. > No, it is not specific to Enterprise IT manged devices. Managed network security can be provided by ISPs, Home router integrated with security service, BYOD policies in Enterprise networks etc. Cheers, -Tiru > > Paul > --000000000000c26c3605948fb593 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 9 Oct 2019 at 15:05, Paul Wouters= <paul@nohats.ca= > wrote:
On Tue, 8 Oct 2019, tirumal reddy wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0How and how would any enforcement system wor= k for a variety of DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0providers all over the world? ISPs? hotels? = coffeeshops? Mobile
>=C2=A0 =C2=A0 =C2=A0 =C2=A0providers? Will there be an industry standar= d org? How will this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not devolve into government sanctioned manda= tory DNS providers on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0my mobile device?
>
> Users may or may not trust the attached network and the DNS server pro= vided by the network (e.g, a public
> network). It is similar to the way users disable VPN in specific trust= ed networks (e.g., Enterprise network)
> and VPN is enabled by default in all other networks.=C2=A0=C2=A0

The user can already do that, without any help from the local network.
If someone configures a VPN or a DoT/DoH, they do not need the local
network for anything except passing a captive portal. I don't understan= d
what you are adding here.

Trust relationships of networks are:

1) I don't need to trust them, so I don't
2) I am forced to trust them, so I do.

In the case of an enterprise network like 2) they can already
pre-install the CA certs I need to trust on connecting to the
network (see the IETF network do something similar there)
<= div>
I am referring to BYOD devices, BYOD will not have Enter= prise root certificate and cannot be provisioned with the Enterprise DoT/Do= H server using AD. The owner of the the BYOD has a choice whether to use th= e Enterprise network provided DoT/DoH server or not.=C2=A0
=C2=A0=

> No. If the privacy requirements of the endpoint are not met, the DNS c= lient can discard using the discovered
> DNS server in the attached network, and connect to a public DNS resolv= er meeting the endpoint=C2=A0privacy
> preserving data policy requirements.=C2=A0

Again, it is the other way around. Users should not need or want to
trust the local network. My laptop mostly connects to completely unknown networks with zero trust _or_ a trusted enterprise network. What are
these networks that a user should "trust to filter or log their DNS fo= r
them" ?

> The proposed mechanism also helps the DNS client to automatically lear= n updates to the privacy claims by a DNS
> server and avoids the need for users to periodically manually review t= he privacy statement.=C2=A0

Again, this is fixing a problem that I do not think exists. Why should I trust or not trust this network with DNS to begin with? Their privacy
policy update will not change that for me. Either, they were already too weak for me to trust, so I don't care about their DNS privacy policy update, or I trusted them already, in which case it seems I trust them
more than my own trusted DNS - AKA I'm forced to trust them (an
enterprise network).

I disagree, user n= eeds to know whether his privacy requirements are met by the local DNS serv= er or public DNS server. If the public DNS server decides to change the pol= icy to sell user data to third-parties, the user would want to move to a di= fferent DNS server.=C2=A0
=C2=A0

> The=C2=A0privacy policy information helps make the decision whether th= e DNS provider can be trusted or not.=C2=A0

No it does not. It can only tell me when I for sure cannot trust them.
Since I did not audit their logging, I can never be sure to trust them.
=

An end-user cannot audit the privacy claim= s by any DNS provider including the public DNS revolvers, and can possibili= ty rely on the audits performed by third parties (similar to way VPN provid= ers use third party audits).=C2=A0 How does the user know the public DNS se= rver has not made false privacy claims ?
=C2=A0

It's like saying a privacy policy will select whether I use HTTP:// or<= br> HTTPS://. That is not the question. The question is why would I ever
use HTTP:// ?

>=C2=A0 =C2=A0 =C2=A0 =C2=A0I'm still not convinced this statement i= s wrong. And additionally can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0see some serious harmful effects into mandat= ory censorship if this kind
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of system becomes mandatory on people's = devices.
>
> I disagree, the proposal helps the user to choose a DNS server that be= st supports the desired privacy
> policies.

I either have a really good DNS provider that I fully trust up my
sleeve, or I don't. If I do, I don't need the local network one. If I don't, I have no choice but the use the local network one.

Local DNS server for several reasons, blocking= malware and phishing, enforce MUD rules to only allow intended communicati= ons to and from the IoT devices. Several other reasons like "CDN endpo= int selection" are listed in=C2=A0https://tools.ietf.org/html/draft-reid-doh-o= perator-00
=C2=A0

> DNS clients do not need to fallback to clear text DNS, and can use the= DoT/DoH server provided by
> the local network.

Then why should I ever take a risk that this local network has a privacy policy that does not actually match its implementation?

Firefox falls back to clear text DNS because the local net= work has parental control or DNS filtering. Android has an option to automa= tically use to the local DoT server (opportunistic mode).=C2=A0
= =C2=A0

> Further, it also provides a mechanism to securely signal to the DNS cl= ient that the
> attached network performs DNS filtering.=C2=A0

You cannot signal securely unless I have a trust anchor already on my
device that would be used. If this is a CA-type store of hundreds of
trust anchors, I cannot really trust them for this decision over a
personally selected known safe choice.

You= may want to re-look into the Security and Privacy considerations sections,= we are not suggesting to rely on the hundreds of trusted anchors on the br= owser/OS.=C2=A0
=C2=A0
If it is enterprise specific,
we already have mechanisms in place for securely obtaining updated DNS
mechanisms. Like via VPN using RFC 8598.

No, it is not specific to Enterprise IT manged devices. Managed network s= ecurity can be provided by ISPs, Home router integrated with security servi= ce, BYOD policies in Enterprise networks etc.=C2=A0

Cheers,
-Tiru
=C2=A0

Paul
--000000000000c26c3605948fb593-- From nobody Thu Oct 10 08:12: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 214E812008B for ; Thu, 10 Oct 2019 08:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 PvGNC2pj6sWs for ; Thu, 10 Oct 2019 08:12:38 -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 0AB5012001A for ; Thu, 10 Oct 2019 08:12:38 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id n197so14440188iod.9 for ; Thu, 10 Oct 2019 08:12:38 -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=c6zg5+G+Tc+o/gGRENKli7vk8BsiWwMpODmmyl1+dsQ=; b=BYiyVkMYA9RGviC8STxgiqOZ5Vq59lnCPBo98Ym4dC0rYI7kK0Ogc47z3GgYKIoJ4u UVrqLcB1WmephHbGjPhGV1/Y0Ef/wsH9KfgKKbBmNaGPt6PTNfsQLps/0wwLRxMNioUi AnmfPvI/auCHcoTyxb4lIcaBbIcTIqUdKsS39keR+XVgvcbmfB7jhZHMQQrkGJjCzMHL 6VirwLaTweTSMokAseEYWrGRUIMJA9UYUQI0D52fLNz2OgPkaadjk2Yfsb7wAQ+Akds2 GiYFlkrcodiTu6fKDiEyzGKjBBCXu2zrKIpw2+ZgQuiYWwtbMDqzMBmZRNG44/uxXNFR u2Lw== 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=c6zg5+G+Tc+o/gGRENKli7vk8BsiWwMpODmmyl1+dsQ=; b=MhBCJeTjkruLRSa7LhqEZODkYt3Ce4z1owniivKZ7fBD9eMKw9erc6OR6kqYkiAKRA d2bS0tNxRvGh0ZOhEKrq3MDyCjo6UhYekWZhq/qa2FFwY+o911tUNaOeGo0D3HjQ31r4 uWHNI77hY2IdpXYMKBYUu7h8tq10IJkznWt1Tf+xxTOiiVmAM0b7x6IdSl6XTPZvunCY 8+v7BdB7sPlcvwtGvn/5enWpa0PGT31tOsrsV88gSY7H6iU97a7+WFDI5Pwbh25oubj7 iPv44MeuQYzLuod/GOQ9XvpriuObXceqgJi3Hz6H0T0OHrnB1ruP9f2lDBkNx7rsf7Wn At2w== X-Gm-Message-State: APjAAAWpK6Pnm2aS/KZdr9z/L550FTVha8RdF62uzbohxsVzW24V8KOT TWsU2Z+yhyWj7SkkOBQGaS9Er5w4AvxneJ9eKbA= X-Google-Smtp-Source: APXvYqxAMYhS6/vB4kSLtDVPBYKrrS/AF5xZHbZj+4LPnoSfMOrR+kYm8a9Zzu2LWJ25eQqO4k/ukDWV0LKvVVgU1DQ= X-Received: by 2002:a6b:e605:: with SMTP id g5mr671663ioh.298.1570720357316; Thu, 10 Oct 2019 08:12:37 -0700 (PDT) MIME-Version: 1.0 References: <4050.1570707771@dooku.sandelman.ca> In-Reply-To: From: tirumal reddy Date: Thu, 10 Oct 2019 16:12:24 +0100 Message-ID: To: Rob Sayre Cc: Barry Leiba , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f0835b05948fd482" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 15:12:41 -0000 --000000000000f0835b05948fd482 Content-Type: text/plain; charset="UTF-8" On Thu, 10 Oct 2019 at 15:48, Rob Sayre wrote: > On Thu, Oct 10, 2019 at 7:08 PM Barry Leiba > wrote: > >> For that matter, even having a BoF in Singapore isn't set in stone: if >> you, the community, think we've erred in assuming that a BoF now is >> the best approach, and we get rough consensus on that, we can easily >> cancel the BoF between now and then. >> > > These two drafts seem well-intentioned: > > https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-00 > https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-00 > > Why not just handle them in the DPRIVE WG? > There are several other drafts: https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-00 https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05 https://tools.ietf.org/html/draft-peterson-dot-dhcp-01 https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 -Tiru > > I don't think a 200-person BoF in Singapore will get a better result. > > thanks, > Rob > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000f0835b05948fd482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 10 Oct 2019 at 15:48, Rob Say= re <sayrer@gmail.com> wrote:<= br>
On Thu, Oct 10, 2019 at 7:08 PM Barry Leiba <barryleiba@computer.o= rg> wrote:
For that matter, even having a BoF in Singapore isn't set in stone: if<= br> you, the community, think we've erred in assuming that a BoF now is
the best approach, and we get rough consensus on that, we can easily
cancel the BoF between now and then.

Th= ese two drafts seem well-intentioned:


Why not just h= andle them in the=C2=A0DPRIVE WG?
--000000000000f0835b05948fd482-- From nobody Thu Oct 10 08: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 39B881200DB for ; Thu, 10 Oct 2019 08:18:20 -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_HELO_NONE=0.001, 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 2tUAirQKv2Qo for ; Thu, 10 Oct 2019 08:18:18 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 A4FA8120026 for ; Thu, 10 Oct 2019 08:18:18 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id w12so14461217iol.11 for ; Thu, 10 Oct 2019 08: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=we+MheUDmQqTabTjIylUpECQ2TSTPDe8BBl50IK0UXQ=; b=kFa7D99/BO2J1s24e9fdeIUEmRfhPWzYutkLVHF5CWWinlnWy3IrYWEhcR+w3uyesl VLsWpt+e/+A2RwGOPLO6ZwU8a9mBBTJ6gu+xeSbTDMoflm/pKxgwtgxKBVuHd5yh/5wd pVzQlpu+AneZdbuMDHgN6BQ6/dV9TRrcqaPtwkLa02PsQDFd033m7qSWFaQHZMr8g8xY E+fP650FHCavjdyZfKcyfhWYCCPYKPvT8ta6PUnaz0w0ZgEY4VYQWKnoxj8+tj4rSOZi RtgxmBHj4t4OOgBGH9NewhMYLixhprhhBWspV7I/Pl/xA96umxfSR0D61cSCLRc4j3kX ODWg== 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=we+MheUDmQqTabTjIylUpECQ2TSTPDe8BBl50IK0UXQ=; b=n+2XhiaEYEiIuV+UdUgGkduqTEmibjyLaT0Wm/xYZWCbdiCE+Fp3jnHMOd3XJ8XLy+ /6+NN1mPDHU6mnMblRIy9Usr7wtN+5E01tNnVIisbzCjSg84kDzere0dLEARCG6fhyMW qlPUXS+TQ0L2bEywwjxpktCPbQFoiSGTuBNknNBSRZLwtEV+h2IyIVnTC9ucE9HS9Fyi q8KFtnLVxDDSgOJjchkRQHhVsSWTNAbS+LB03ZkWQwt5ujSKGD/J/11XOeyVmbBZojug hqEivAt1oSWEJrmqu5G4Eg3cjIzZemi+LA2pe5nI6TgMC7+F2HTXCJCpWtkel8XTcsgB yDJg== X-Gm-Message-State: APjAAAXiv3dW1umRYsh0PotcnlsYn0L6KdtsKhzmd3kqUkKPdju/cbY/ udRdiaBegWsf55iQ9x0fyJrXUCKKSE0b7j8T62Y= X-Google-Smtp-Source: APXvYqwZFU3RbY+kkW6/oWD7D1wEU2RYHNeQQXYQL9NKxuyz3UjxzXq+nnXtOnjPbT0H/xBnuqzUFqlDsydoyBOnwaQ= X-Received: by 2002:a5d:9297:: with SMTP id s23mr11514748iom.49.1570720697102; Thu, 10 Oct 2019 08:18:17 -0700 (PDT) MIME-Version: 1.0 References: <4050.1570707771@dooku.sandelman.ca> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 22:18:05 +0700 Message-ID: To: tirumal reddy Cc: Barry Leiba , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000031391d05948fe94a" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 15:18:21 -0000 --00000000000031391d05948fe94a Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 10:12 PM tirumal reddy wrote: > > There are several other drafts: > Hi Tiru, Thank you for mentioning those documents. One of them already seems to be a DNSOP WG production. Are you implying a BoF in Singapore would be productive for the other three documents? Two of them seem to be targeted at DPRIVE. thanks, Rob --00000000000031391d05948fe94a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 10, 2019 at 10:12 PM tirumal redd= y <kondtir@gmail.com> wrote:=

There are several other drafts= :

Hi Tiru,

Thank you for mentioning those documents. One of them= already seems to be a DNSOP WG production.

Are yo= u implying a BoF in Singapore would be productive for the other three docum= ents? Two of them seem to be targeted at DPRIVE.

t= hanks,
Rob
--00000000000031391d05948fe94a-- From nobody Thu Oct 10 08:35: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 BF71F120077 for ; Thu, 10 Oct 2019 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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-dKx0czcB7z for ; Thu, 10 Oct 2019 08:35:43 -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 C30E512001A for ; Thu, 10 Oct 2019 08:35:43 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id b19so14706389iob.4 for ; Thu, 10 Oct 2019 08:35: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=4x6Ni5HZ8ve/am7BjyGfPcHQwh7ELC/xV/od5a+yL4o=; b=nlcjJGYvskgDRGQ5iGkoRx1w0ABXopfgczgG0yU0E2rEh1greZMwY8VLQofrhWEFUU Clh5V4i2N6hxAe/Nh9ojpXwCqJrr9iELqb2janRRpIkor0qwz5xZljH/adJyWXt8FJw8 9TUjR0BF526jw5lBGDUS1yLOtzeEDqRT5cFsOfNx++bNjAp7ywFQR1Fo5pMyfwa3/fQr 0smaFuCcP/SPH0URPa/i9kFSSwaGUplkiF9/pZ745E3YALHwJIn0YYP4xFB9FiFDUvc/ juhWGx3cvKyje77w/HjejN8+JDIS74deVhMs8nBDBJg8DSMucgepSN16VBFO4oUSqKO8 +OCA== 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=4x6Ni5HZ8ve/am7BjyGfPcHQwh7ELC/xV/od5a+yL4o=; b=LwXxBBPUAOxdwm8qmHRGpZ9yvV1d48vIJ2awCkU5kXFghnrVkt2y8z5aqxX/PExQ8S utcyZEpxyivK5R7dfrGVt6c3ED8bgdVg0aVJ+Wm/Jhfq1c+srHzN4BqwAPcTW55sobY9 jL5bGGe+nxREcGkl+w9Oz8OFE7GQ4zl8TkZpuA1JEqo1qNtwvYhztbvyXy6/EFTmWHGR IagEocfiQ5cQSlr083is4yLpI2zsXVQ14rKb5505rRTyPi3SmFH5o+ial7nnFl9nQS0S 8dAQbfupm6T1y2vzi/5F/MonhWlAy0JploTO45qyLHXCDUI5N/iDgisf+Bn3i69ky08u Eotw== X-Gm-Message-State: APjAAAWqFZZu/TNB7y5ZjQBD9Hr+l9yNKP2Qm8JuYKe5hA7sWbYsS9w6 M0Oasl3kk+4Pw5qmCvwYxM+3K2mt+ywh4J5F4Pw= X-Google-Smtp-Source: APXvYqzTivf7IGWep907+jEbXGAp8Bp4iEzdP0/PwrLNzY9tjOIONO1JXDVFSmvnFAwNcmMg5m6AdvayJgkb5qMfGzg= X-Received: by 2002:a02:c610:: with SMTP id i16mr11174714jan.51.1570721742988; Thu, 10 Oct 2019 08:35:42 -0700 (PDT) MIME-Version: 1.0 References: <4050.1570707771@dooku.sandelman.ca> In-Reply-To: From: tirumal reddy Date: Thu, 10 Oct 2019 16:35:30 +0100 Message-ID: To: Rob Sayre Cc: Barry Leiba , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000882c2c05949027e3" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 15:35:46 -0000 --000000000000882c2c05949027e3 Content-Type: text/plain; charset="UTF-8" On Thu, 10 Oct 2019 at 16:18, Rob Sayre wrote: > On Thu, Oct 10, 2019 at 10:12 PM tirumal reddy wrote: > >> >> There are several other drafts: >> > > Hi Tiru, > > Thank you for mentioning those documents. One of them already seems to be > a DNSOP WG production. > Yes, but draft-ietf-dnsop-resolver-information-00 only discusses publishing the resolver information but does not discuss the resolver policy. > > Are you implying a BoF in Singapore would be productive for the other > three documents? > Yes for a BoF to discuss the above documents including the ones from Apple. > Two of them seem to be targeted at DPRIVE. > All the above drafts target both DoT and DoH excluding draft-peterson-dot-dhcp-00. I missed including https://tools.ietf.org/html/draft-peterson-doh-dhcp-00. Cheers, -Tiru > > thanks, > Rob > --000000000000882c2c05949027e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 10 Oct 2019 at 16:18, Rob Sayre <sayrer@gmail.com> wrote:
On Thu, Oct 10, 2019 at 10:12 PM tirumal reddy &= lt;kondtir@gmail.com= > wrote:

There are sever= al other drafts:

Hi Tiru,

Thank you for mentioning those documen= ts. One of them already seems to be a DNSOP WG production.

Yes, but draft-ietf-dnsop-resolver-inform= ation-00 only discusses publishing the resolver information but does not di= scuss the resolver policy.=C2=A0=C2=A0
=C2=A0

Are you implying a BoF in Singapore would be produ= ctive for the other three documents?
Yes for a BoF to discuss the above documents including the one= s from Apple.=C2=A0
=C2=A0
Two of th= em seem to be targeted at DPRIVE.

All the above drafts target both DoT and DoH excluding draft-peter= son-dot-dhcp-00. I missed including=C2=A0https://tools.ietf.org/html/draft-peterson= -doh-dhcp-00.

Cheers,
-Tiru
=C2=A0

thanks,
Rob<= /div>
--000000000000882c2c05949027e3-- From nobody Thu Oct 10 08:45: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 05C25120813 for ; Thu, 10 Oct 2019 08:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 CPxppLAal3Ji for ; Thu, 10 Oct 2019 08:44:54 -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 C225E120116 for ; Thu, 10 Oct 2019 08:44:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pwPw1H0Yz6j; Thu, 10 Oct 2019 17:44:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570722292; bh=6ypgE+k+vhjlc50voZnpAa7TiC40WoiPIiJZNk/LiJY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nzRpeQJoOHf7P7VZfo6U3eJlI8vcrGv63c7OC1oR5533ScsYh9sOUHKzwvlq7tnF5 Qj/u/PV/NW7QpeyriCsL6fjRdMUI38F7tBiOlY9XU5jtmMn0pm9pWcOSe01SFm7/fM Na8IddAIhv9upYn4EKmX82IcwgmKf8cLRxhsccgQ= 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 1J0E0fJSMopf; Thu, 10 Oct 2019 17:44:49 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 10 Oct 2019 17:44:49 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DE2F8606AA24; Thu, 10 Oct 2019 11:44:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DA51723FDDC; Thu, 10 Oct 2019 11:44:47 -0400 (EDT) Date: Thu, 10 Oct 2019 11:44:47 -0400 (EDT) From: Paul Wouters To: tirumal reddy cc: ADD Mailing list In-Reply-To: Message-ID: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 10 Oct 2019 15:45:07 -0000 On Thu, 10 Oct 2019, tirumal reddy wrote: > I am referring to BYOD devices, BYOD will not have Enterprise root certificate and cannot be provisioned with the > Enterprise DoT/DoH server using AD. The owner of the the BYOD has a choice whether to use the Enterprise network > provided DoT/DoH server or not.  I have a BYOD device. My enterprise insists that they have limited control via Google Mobile Device Management. They could dictate to use certain DNS servers when connecting to certain wifi networks. > Again, this is fixing a problem that I do not think exists. Why should I > trust or not trust this network with DNS to begin with? Their privacy > policy update will not change that for me. Either, they were already too > weak for me to trust, so I don't care about their DNS privacy policy > update, or I trusted them already, in which case it seems I trust them > more than my own trusted DNS - AKA I'm forced to trust them (an > enterprise network). > > I disagree, user needs to know whether his privacy requirements are met by the local DNS server or public DNS server. The user cannot know if their privacy requirements are met, with or without a signed XML statement from those parties. The user can only hope. And since the user can only hope, it is by far safer to pick a few or a single trusted party, than to hope each time they connect to a new wifi network. > If the public DNS server decides to change the policy to sell user data to third-parties, the user would want to move > to a different DNS server.  Sure. But a DNS server that is going to betray the user like that, wouldn't be stopped by a signed XML file either. > An end-user cannot audit the privacy claims by any DNS provider including the public DNS revolvers, and can possibility > rely on the audits performed by third parties (similar to way VPN providers use third party audits).  How does the user > know the public DNS server has not made false privacy claims ? The user gains trust through a variety of non-technical, non-protocol ways. News items, journalism, company reputation, prefering a non-profit over an advertisetment company, entity history, people they know, etc. Perhaps even through third party audits similar to mandated CAB/Forum audits. Why do I not trust Sony or LinkedIn? Because they proved to not deserve it in the past. Why do I trust cloudflare or PCH? Because until now, they have proven to commit to their publicly announced policies on their websites and as reported by other experts. > I either have a really good DNS provider that I fully trust up my > sleeve, or I don't. If I do, I don't need the local network one. > If I don't, I have no choice but the use the local network one. > > Local DNS server for several reasons, blocking malware and phishing How relevant is this in reality. Linux and OSX people and all mobile phones do not run anti-malware software. Phising happens mostly via email, which is unaffected by DoH/DoT and can still be done serverside, and search engine results - which are curated by both search engines (google filtering bad stuff) and browsers (eg mozilla preventing me to go to a known malware site). None of this puts any requirements on my DNS provider selection. > , enforce MUD rules to only allow intended > communications to and from the IoT devices. non-mobile IoT devices hardly have a use for encrypted DNS to begin with, and their MUD profiles should not allow it. Those should clearly state "DNS to DHCP supplied resolver only" and "these domains related to my services". Note that this isn't secure unless you could trust the DNS answers, by either local transport or DNSSEC integrity. > Several other reasons like "CDN endpoint selection" are listed > in https://tools.ietf.org/html/draft-reid-doh-operator-00 CDN endpoint tracking is pretty risky from a privacy point of view. The operator might want that, but the user that desires privacy might not. > Then why should I ever take a risk that this local network has a privacy > policy that does not actually match its implementation? > > Firefox falls back to clear text DNS because the local network has parental control or DNS filtering. Android has an > option to automatically use to the local DoT server (opportunistic mode).  Sure, to support the enterprise/parental case voluntarilly. Again, there is hardly a need to codify this in XML. Their users are forced to comply. If I am at starbucks, I am not going to let firefox downgrade me because of "parental control" desire, whether the instructions are XML signed or not. > > Further, it also provides a mechanism to securely signal to the DNS client that the > > attached network performs DNS filtering.  > > You cannot signal securely unless I have a trust anchor already on my > device that would be used. If this is a CA-type store of hundreds of > trust anchors, I cannot really trust them for this decision over a > personally selected known safe choice. > > You may want to re-look into the Security and Privacy considerations sections, we are not suggesting to rely on the > hundreds of trusted anchors on the browser/OS.  If it is a fundamental design item, it should have its own Section on how to implement it. Not just waive some Security and Privacy considerations. > If it is enterprise specific, > we already have mechanisms in place for securely obtaining updated DNS > mechanisms. Like via VPN using RFC 8598. > > No, it is not specific to Enterprise IT manged devices. Managed network security can be provided by ISPs, Home router > integrated with security service, BYOD policies in Enterprise networks etc.  ISPs that are not a utility are defacto an enterprise network. Home routers are parental control or 'enterprise' networks. BYOD devices already have their methods to enforce various things on their respective mobile OS platforms requiring no IETF standards. So your cases are still really enterprise/parental control, where there are tight and mandatory trust relationships. No signed XML needed. As I said before, I haven't seen much upside on this. I do see downsides when this kind of mandatory reconfiguring of my device privacy settings are being forced at the ISP or national level to circumvent my privacy. Maybe think of a Human Rights Consideration Section in the document too as per RFC 8280 ? Paul From nobody Thu Oct 10 08:52: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 DFA8812029C for ; Thu, 10 Oct 2019 08:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 wc48j4m0m5P1 for ; Thu, 10 Oct 2019 08:51:55 -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 86AA11200C1 for ; Thu, 10 Oct 2019 08:51:55 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id a1so14822464ioc.6 for ; Thu, 10 Oct 2019 08:51:55 -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=83OFaUJ6fHIySNbHk0djbYwxKvGdflJcIWAuOVV4Wgc=; b=MbvnWSP8mOFQxrQK/GH4vyxd7LR3STGs/HmlX8ju1cB5Zi9Ko6UIYxSxu6s0vgil+7 2mrQ0KO0QBMN4ZG2H6hmUjtuDnzPu2KOx3rq/Nn02KutBbvQnhBhXnHIq8DUsWdnPY8R FgYXumd2CYn8HvGVVxUytJFuePW18PyX/RkIfEO1xNR/uKzoyedW2zcEYx55DtkSrb/t SNoo5rICDoCO1QXMCDVeUgF9vXRt/tNyY2IPhacS6R1zqp9Vkx69bdVsuDo4ofA0sXwW ATRxgyH16jjV9o5QNDojC4GffT7Cu89Iuz3W6sxd5cVtjL2ThB238QUW6mMzi5ybMymb ETpg== 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=83OFaUJ6fHIySNbHk0djbYwxKvGdflJcIWAuOVV4Wgc=; b=Fkg+SBrE/KLkawNlu+p9xZ6dEc1HEyRRHUzPomhE3uib3YjGvVJpZh6+xmvzNPQKbR WlPtuCdVUr5hEKvUbwyrXPECCZmoDp930zDoSWEbrcpRbqyis6C9yzLBBC5Dwa5vvGz6 JZBcU4GBJZvz9GntKXTGAeV9KQ7+FcdQX6BOP+dCyOREmR7TXNzaDpPlnDYyg9rLA2Iw 3RBzOqnIVyO9/GMEcq+l8xAN/kJbsIP68gDqgh/WK/dSzmlB4qECo+aQQfJmD0jMPRNE YUiTpwQZ5CUP5kA68fQTsy6XqQMCa6WXsHErIw1k6pu2Zhtxj/7Y5GSoihI29FVVYXz7 SbpQ== X-Gm-Message-State: APjAAAVfauhdJhbfUlesROoLvd8BitHZ819vnQkbKTL/XRR3a5kfftPb 0nCJF8tGwJcrt0MejXg/4AFmkh+sl/vnMDUyFLliiSU83Uo= X-Google-Smtp-Source: APXvYqzIuqT9GTmTiENi5h08orQTf4OI/xx4TXq2G48immgIB4H0LCK9ut5t6cbDg8dmtKEUj55vPw9N/O7AhMLD1vo= X-Received: by 2002:a02:c610:: with SMTP id i16mr11263805jan.51.1570722714726; Thu, 10 Oct 2019 08:51:54 -0700 (PDT) MIME-Version: 1.0 References: <1556423899.28427.1570640191209@appsuite-gw2.open-xchange.com> In-Reply-To: From: tirumal reddy Date: Thu, 10 Oct 2019 16:51:41 +0100 Message-ID: To: Eric Rescorla Cc: Paul Wouters , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000073b5420594906113" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 15:51:59 -0000 --00000000000073b5420594906113 Content-Type: text/plain; charset="UTF-8" On Wed, 9 Oct 2019 at 19:32, Eric Rescorla wrote: > > > On Wed, Oct 9, 2019 at 11:04 AM tirumal reddy wrote: > >> On Wed, 9 Oct 2019 at 18:15, Paul Wouters wrote: >> >>> On Wed, 9 Oct 2019, Eric Rescorla wrote: >>> >>> > You're misunderstanding me. I'm not saying that we should not enable >>> network operators to shift to encrypted transport. >>> > As I said in the section of my message that you cut, I'm more than >>> happy to have the IETF standardize a mechanism for >>> > the network to tell endpoints that it supports encrypted transport. >>> I'm merely observing that this does not address the >>> > issue that Mozilla is trying to address with our DoH/TRR deployment. >>> >>> And it seems doing this at the DHCP / Captive Portal level is enough. I >>> don't see the need for a WG to be spun up for this. >>> >> >> DHCP is not a secure way to discover the local DoT/DoH server. >> > > It would probably useful to start by defining what "secure" means in this > context. > "secure" means only the operator of the network should be able to advertise the DoT/DoH server. If DHCP is used, attacker can spoof the DHCP response. > For instance, I am in an airport and I see the name of the WiFi AP printed > on the wall an join a network with that SSID. How would you define securely > learning the DoH server? > The user cannot know the SSID is hosted by the airport IT admin or by an attacker in the first place. I don't think the charter of the WG is targeted only for public WiFi, local resolver discovery is critical in Home, Mobile and Enterprise networks to meet some of the issues raised in https://tools.ietf.org/html/draft-reid-doh-operator-00. -Tiru > > -Ekr > > >> -Tiru >> >> >>> >>> Paul >>> >>> -- >>> Add mailing list >>> Add@ietf.org >>> https://www.ietf.org/mailman/listinfo/add >>> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --00000000000073b5420594906113 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 9 Oct 2019 at 19:32, Eric Rescorl= a <ekr@rtfm.com> wrote:
=


On Wed, Oct 9, 2019 at 11:04 AM tir= umal reddy <kondt= ir@gmail.com> wrote:
On Wed, 9 Oct 2019 at 18:15, = Paul Wouters <paul@n= ohats.ca> wrote:
On Wed, 9 Oct 2019, Eric Rescorla wrote:=

> You're misunderstanding me. I'm not saying that we should not = enable network operators to shift to encrypted transport.
> As I said in the section of my message that you cut, I'm more than= happy to have the IETF standardize a mechanism for
> the network to tell endpoints that it supports encrypted transport. I&= #39;m merely observing that this does not address the
> issue that Mozilla is trying to address with our DoH/TRR deployment.
And it seems doing this at the DHCP / Captive Portal level is enough. I
don't see the need for a WG to be spun up for this.

DHCP is not a secure way to discover the local DoT/DoH ser= ver.

It would probably us= eful to start by defining what "secure" means in this context.

"secure" means o= nly the operator of the network should be able to advertise the=C2=A0 DoT/D= oH server. If DHCP is used, attacker can spoof the DHCP response.=C2=A0
=C2=A0
For instance, I am in= an airport and I see the name of the WiFi AP printed on the wall an join a= network with that SSID. How would you define securely learning the DoH ser= ver?

The user cannot = know the SSID is hosted by the airport IT admin or by an attacker in the fi= rst place. I don't think the charter of the WG is targeted only for pub= lic WiFi, local resolver discovery is critical in Home, Mobile and Enterpri= se networks to meet some of the issues raised in=C2=A0https://tools.ietf.org/html/d= raft-reid-doh-operator-00.=C2=A0

-Tiru
=C2=A0
--00000000000073b5420594906113-- From nobody Thu Oct 10 08:52: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 3FE8F1200C3 for ; Thu, 10 Oct 2019 08:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh_ByZx-NZm9 for ; Thu, 10 Oct 2019 08:52:34 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 8AC9912001A for ; Thu, 10 Oct 2019 08:52:34 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id n7so9388305qtb.6 for ; Thu, 10 Oct 2019 08:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wfEfSHox+6kyBUacrqFim5ObKZniPlo9bMyt+TryHIU=; b=skr3FRcJMHumCShI3ZiR/TMzZH9n3J0uI90qorkaehrEldQtNCsttutJSm5cZUjTuR m6afAJ7k4+xuVa3mTxgoKKuLkRiOM+vE3TykWcymtn1A306JX94XRARDWhAFSdwbAJ5f zj6RpssyBSN0sNHuMJ/CfzVRr32+EJ9NlMh3Az7ktXiOFvE35l9WItq+7Loe9+trIxr7 Bcqmm7n7ftI3KBRdKovTlN2T0Eilc41oRGoS0ek+R4oyUVV8ArJg9KaJPgO6L8DO3Q1E SPzpouy8ic0AP91x4/NeBmrmaJWLLH8p7w0A6YEDewhe79UnbbuI4gr2ZxQ9xRRVNs7/ a6DQ== 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=wfEfSHox+6kyBUacrqFim5ObKZniPlo9bMyt+TryHIU=; b=qNzCB0ci7nTr19xRR1a18HKTb8zgx/bxdMAC1iz+ZCjhwkzbZHQk5l9oPLwpECaZk/ VofcPZma4cSRrg0Vkj1fMPA3mZpu7tLt87BcxW4Y/x81K9fEL/Lr6wYND83711CuHtNy P90vV7k7toRAcTlATU6O0mnwECl+RrpHZ7mnQhP4a3Iyt/0V/1gY4KsFiiO8IMx9gvSd Htt3a0G7opArxdsCsJq0WFkcTKktS+1IR3GqcyAGkmbJ2d89h5ypJ64ZJOtRF1UKq3nn QEXAuB/l15EHO/Ry3/ZgZvPqwwxEITLy4mIPiBrRTSTrWWoapqw950RQrwD2QVH76Nk/ iVpQ== X-Gm-Message-State: APjAAAV/TZmZwuADWugaeKDQ+GpexoPiHT+Xai7P1YM3X3glGvyob0QG lZvn/yHifAJPX3NcC1jfxvdNbQ== X-Google-Smtp-Source: APXvYqzoh9Iz91e+APBA4sXQBdPhkDkut3DixgECOPuHN+NVmuZAQMUS0mFuHobOeQRXZwsJ68lytQ== X-Received: by 2002:ac8:2a66:: with SMTP id l35mr11659436qtl.340.1570722753366; Thu, 10 Oct 2019 08:52:33 -0700 (PDT) Received: from [10.0.10.46] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id x33sm2909854qtd.79.2019.10.10.08.52.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Oct 2019 08:52:32 -0700 (PDT) From: Ted Lemon Message-Id: <31B0777B-E854-4526-89E1-9B4D5302F5E4@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6DC3A111-CC8A-4D15-AB54-46A619A35424" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Thu, 10 Oct 2019 11:52:30 -0400 In-Reply-To: Cc: Rob Sayre , Barry Leiba , ADD Mailing list To: tirumal reddy References: <4050.1570707771@dooku.sandelman.ca> X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 10 Oct 2019 15:52:37 -0000 --Apple-Mail=_6DC3A111-CC8A-4D15-AB54-46A619A35424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 10, 2019, at 11:35 AM, tirumal reddy wrote: > Yes for a BoF to discuss the above documents including the ones from = Apple.=20 Why is this better than discussing them in dprive? Talking about = documents that already have homes seems like a poor justification for = having a BoF: sufficiently poor that if that is the stated goal of the = BoF, there is a tendency to wonder what the unstated goal might be. I = don=E2=80=99t mean to suggest shenanigans=E2=80=94what I mean is that = there is some ur-idea behind this BoF that perhaps hasn=E2=80=99t even = been clearly expressed among the proponents, and that would be useful to = surface. When I look at the proposed charter, I don=E2=80=99t really see it = talking about stuff that we can reach consensus on. I think there are = some interesting questions being asked here, but I don=E2=80=99t think = there=E2=80=99s any kind of consensus on the answers. As Martin said, I think it could be useful to have an IAB workshop on = this to explore those topics, and maybe see if there are schools of = thought on the various issues mentioned here. I suspect there are. = If these could be captured in a non-consensus document that simply = explains what the various beliefs are clearly and with sufficient = background that they can be reasoned about, that could be a substantial = improvement over the discussion we=E2=80=99ve been having here. But I don=E2=80=99t see that happening in a 200-person BoF. And the = idea that we would charter a working group without having done that, = with a charter to act on the stated work items, just seems like another = chaff-generating activity. I certainly agree that there are issues to = discuss here; I just don=E2=80=99t believe that a working group = chartered to reach consensus on these topics is a good approach at the = present moment. --Apple-Mail=_6DC3A111-CC8A-4D15-AB54-46A619A35424 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 10, 2019, at 11:35 AM, tirumal reddy <kondtir@gmail.com> = wrote:
Yes = for a BoF to discuss the above documents including the ones from = Apple. 

Why is = this better than discussing them in dprive?  Talking about = documents that already have homes seems like a poor justification for = having a BoF: sufficiently poor that if that is the stated goal of the = BoF, there is a tendency to wonder what the unstated goal might be. =   I don=E2=80=99t mean to suggest shenanigans=E2=80=94what I mean = is that there is some ur-idea behind this BoF that perhaps hasn=E2=80=99t = even been clearly expressed among the proponents, and that would be = useful to surface.

When I look at = the proposed charter, I don=E2=80=99t really see it talking about stuff = that we can reach consensus on.   I think there are some = interesting questions being asked here, but I don=E2=80=99t think = there=E2=80=99s any kind of consensus on the answers.

As Martin said, I think it could be useful to have = an IAB workshop on this to explore those topics, and maybe see if there = are schools of thought on the various issues mentioned here.   I = suspect there are.   If these could be captured in a non-consensus = document that simply explains what the various beliefs are clearly and = with sufficient background that they can be reasoned about, that could = be a substantial improvement over the discussion we=E2=80=99ve been = having here.

But I don=E2=80=99t see = that happening in a 200-person BoF.   And the idea that we would = charter a working group without having done that, with a charter to act = on the stated work items, just seems like another chaff-generating = activity.   I certainly agree that there are issues to discuss = here; I just don=E2=80=99t believe that a working group chartered to = reach consensus on these topics is a good approach at the present = moment.

= --Apple-Mail=_6DC3A111-CC8A-4D15-AB54-46A619A35424-- From nobody Fri Oct 11 02:11: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 8B2B11207FC for ; Fri, 11 Oct 2019 02:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, 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 qg9zlMHwkt5Y for ; Fri, 11 Oct 2019 02:11:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC0E12025D for ; Fri, 11 Oct 2019 02:11:16 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [46.183.103.8]) by relay.sandelman.ca (Postfix) with ESMTPS id 2E3FD1F47F; Fri, 11 Oct 2019 09:11:14 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8976C34B4; Fri, 11 Oct 2019 11:11:42 +0200 (CEST) From: Michael Richardson To: Paul Wouters , ADD Mailing list In-reply-to: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> Comments: In-reply-to Paul Wouters message dated "Thu, 10 Oct 2019 11:44:47 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Fri, 11 Oct 2019 11:11:42 +0200 Message-ID: <17104.1570785102@dooku.sandelman.ca> Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 11 Oct 2019 09:11:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > On Thu, 10 Oct 2019, tirumal reddy wrote: >> I am referring to BYOD devices, BYOD will not have Enterprise root >> certificate and cannot be provisioned with the Enterprise DoT/DoH >> server using AD. The owner of the the BYOD has a choice whether to u= se >> the Enterprise network provided DoT/DoH server or not.=C2=A0 > I have a BYOD device. My enterprise insists that they have limited > control via Google Mobile Device Management. They could dictate to use > certain DNS servers when connecting to certain wifi networks. And when you visit my enterprise as a consultant, you will permit my company to do the same to your devices? Maybe I should ask that different: will RedHat IT Security let me do that to your company device, which is effectively a BYOD when it visits? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2gR04ACgkQlUzhVv38 QpC95gf9EvBGd1vm6iU3Jc5lrGH5HbxXgd2vtSjpY60XkuO2XB2XZEg0o31XXg1H GoLtF6k7P9kJ8sUH5L9SkdFCL0jjohzr7+w8rKJOCMvlMdVR+7QUvhr3WzUqPAJY fa0J8P5NrOWRtn/CjYZzlljFo1Rk1gy7R1E4VsrtySzhCxJuUimVJ0W27M9gKVe5 fkZHVIjGjhAMh7EiGaCNHAjkt82CY4rwYmFKIOPp5BmyqM93GuMRQv8gkwMVZDu/ YDXFxVw4qb7bNU7Zabc4+h7WjyaSd6noIjQSh2eoaKoCYTVsy5gXkvR86qFAoZ/B yB+IC8LVaCgiwlNzSDRQUW36bPbwrA== =P+lA -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 11 06:54: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 2831D120073 for ; Fri, 11 Oct 2019 06:54:38 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 mVYPWhwpN2-W for ; Fri, 11 Oct 2019 06:54:36 -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 12CD212004D for ; Fri, 11 Oct 2019 06:54:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46qTwB2Ns5zD3m; Fri, 11 Oct 2019 15:54:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570802074; bh=p1d84EQviOya58ob5R/PPk6k1D+EXKnpOeiCuS9BoCo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lvjHDxrxXX87alCVi4j3MFHCMjx+ApwDq1WG6/lG73Vd6Gr+wzlCPhHiRboyQN/3W imfVvuD3NKgUwtL3ZLJxq+IiLxDj08jAE6iO7seFw/3iIrqunJNj0GQ8L4gUbe3mcD St1ZZZwHsh59S7SGnl4Z2C516e/3VjA59FjI4Hqk= 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 bYcmkf4MXHpl; Fri, 11 Oct 2019 15:54:33 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 11 Oct 2019 15:54:33 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CB39B606AA2A; Fri, 11 Oct 2019 09:54:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C7ABC25EAA7; Fri, 11 Oct 2019 09:54:31 -0400 (EDT) Date: Fri, 11 Oct 2019 09:54:31 -0400 (EDT) From: Paul Wouters To: Michael Richardson cc: ADD Mailing list In-Reply-To: <17104.1570785102@dooku.sandelman.ca> Message-ID: References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> <17104.1570785102@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 11 Oct 2019 13:54:39 -0000 On Fri, 11 Oct 2019, Michael Richardson wrote: > > I have a BYOD device. My enterprise insists that they have limited > > control via Google Mobile Device Management. They could dictate to use > > certain DNS servers when connecting to certain wifi networks. > > And when you visit my enterprise as a consultant, you will permit my company > to do the same to your devices? Either I don't need your network, and I won't. Or I need your network, and I have no choice. No signed xml will change that. > Maybe I should ask that different: will RedHat IT Security let me do that to > your company device, which is effectively a BYOD when it visits? That is all defined in their mobile device management solution. They can or cannot. Your signed xml will surely not make a difference to their configuration they pushed onto my phone. Paul From nobody Fri Oct 11 06:58:32 2019 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 642CD12003F; Fri, 11 Oct 2019 06:58:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, abcd-chairs@ietf.org, add@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157080231033.29196.9923200973037333443.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2019 06:58:30 -0700 Archived-At: Subject: [Add] abcd - New Meeting Session Request for IETF 106 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 13:58:31 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the abcd working group. --------------------------------------------------------- Working Group Name: Application Behavior Considering DNS Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Technology Overlap: dprive dnsop artarea People who must be present: Barry Leiba Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Oct 15 04:02: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 933971200DF for ; Tue, 15 Oct 2019 04:02:04 -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_HELO_NONE=0.001, 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 pUheVuRgdNlY for ; Tue, 15 Oct 2019 04:02:01 -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 C77671200EF for ; Tue, 15 Oct 2019 04:02:00 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id q1so44922295ion.1 for ; Tue, 15 Oct 2019 04:02:00 -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=RWkopp+vGmXgpaNj3HfIBxHYlp705hW0qkgzE/g7ymc=; b=YxBmgFc2/Ha0ZzX84AYc+OEiPcixgOD2P1FsuZgQG2aytYlLZaY5iF7HE5Z0WEa+0L Ov26eE+gd9SbRJnYkIN8+N2Lm3d4j/o65wZjv37/EhmwudYJOs7oobk1ye5Mzp1tJt0F VxU2ZbOmYkDiTHKY6OsH3ewRbI8JuHb5NsVel2Ep8FDbkoK7z87uPrDtezvDNQPjFyho fXu02jwIXUUB1sZCWiZ0uQ7nNWB1a/XB/NUjZHdboL7rqHPnMk9DSavP5StGQgMm3E4Y qGrK7I94/H5cU33CQ4556LV6tbkajfTIlea0uLU6pz2h+3Xhr/7skskBVbiZXTXS9Fsw 1reA== 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=RWkopp+vGmXgpaNj3HfIBxHYlp705hW0qkgzE/g7ymc=; b=UvSXzGhgzGZdFiE1su2Z0s82HRo6YKouh+6vt9pWqX7Fc2ItR4hQRnLz42I1FG8Fpn /9F++18hFtK9gr/9rQnyywCqfqDpiw99Qw3+b3E401VfPSTSB/C+X5eskmp9gnJK2Riq Q5zrQwwGlKLShbr4ty/vKAJt2AWFSYynXVay5SMb/BFlcAOLgmozS5zsZaF/zgy2Ocfq YiEf55ODUM/xSLsbvNvPmfsdELOiOcbR6CFXudoVGcT8ZTraf9wMMaLFkl9OziE5Y6I4 jxerdfH1WIa76A37tM2+NPw8Umu5hTNWn7pqqyb40zehAW8JtlK8AAHpl1qDjWNt3q+m nkYA== X-Gm-Message-State: APjAAAXHGSJfXlwm2FiP/hjQjBcTeE2y1GRswFhVfULB4E05PRH2d91R NHc7Yi3VmvGIwcdaDyoqUstFL3MSHajVagd3e/4XRfSL X-Google-Smtp-Source: APXvYqw6X+6I6IiPtUw19YJy4EkFFkOMq6wAo0Yj9+lI9DkWq5lBUGs68UwfY2Bwx5sD4mdz53LsclSUF//Fwk7lTv0= X-Received: by 2002:a6b:e605:: with SMTP id g5mr21767536ioh.298.1571137318902; Tue, 15 Oct 2019 04:01:58 -0700 (PDT) MIME-Version: 1.0 References: <157009854908.16293.4269133049514081713.idtracker@ietfa.amsl.com> In-Reply-To: From: tirumal reddy Date: Tue, 15 Oct 2019 16:31:46 +0530 Message-ID: To: Paul Wouters Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c962230594f0e9ea" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt 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, 15 Oct 2019 11:02:05 -0000 --000000000000c962230594f0e9ea Content-Type: text/plain; charset="UTF-8" On Thu, 10 Oct 2019 at 16:44, Paul Wouters wrote: > On Thu, 10 Oct 2019, tirumal reddy wrote: > > > I am referring to BYOD devices, BYOD will not have Enterprise root > certificate and cannot be provisioned with the > > Enterprise DoT/DoH server using AD. The owner of the the BYOD has a > choice whether to use the Enterprise network > > provided DoT/DoH server or not. > > I have a BYOD device. My enterprise insists that they have limited > control via Google Mobile Device Management. They could dictate > to use certain DNS servers when connecting to certain wifi networks. > No, Enterprise BYOD policy may not mandate MDM on the device. On the other extreme, Enterprise BYOD policy can mandate the MDM on the BYOD to install Enterprise root certificate. > > > Again, this is fixing a problem that I do not think exists. Why > should I > > trust or not trust this network with DNS to begin with? Their > privacy > > policy update will not change that for me. Either, they were > already too > > weak for me to trust, so I don't care about their DNS privacy > policy > > update, or I trusted them already, in which case it seems I trust > them > > more than my own trusted DNS - AKA I'm forced to trust them (an > > enterprise network). > > > > I disagree, user needs to know whether his privacy requirements are met > by the local DNS server or public DNS server. > > The user cannot know if their privacy requirements are met, with or > without a signed XML statement from those parties. No, the proposed mechanism conveys signed privacy policy information to the DNS client and the privacy policy contains a URL that points to the human readable privacy policy formation of the DNS server. The privacy policy can also be signed by a third party who performed privacy and security audit of the DoT/DoH server. Most importantly, user has to select specific networks to learn the privacy claims of local DoT/DoH server and user consent is required to use a locally-discovered DoT/DoH server. Further, the client can learn updates to the privacy claims by the public DNS server, and the user does not have to periodically manually review the privacy statement of the DNS server. > The user can only > hope. And since the user can only hope, it is by far safer to pick > a few or a single trusted party, than to hope each time they connect > to a new wifi network. > The draft is not proposing to select the local DoT/DoH server in all connected networks, see https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00#section-9 > > If the public DNS server decides to change the policy to sell user data > to third-parties, the user would want to move > > to a different DNS server. > > Sure. But a DNS server that is going to betray the user like that, > wouldn't be stopped by a signed XML file either. > The point is the DNS provider becomes liable to penalties and will act as a deterrent to lie (similar to the way FTC has imposed fine on Facebook). > > > An end-user cannot audit the privacy claims by any DNS provider > including the public DNS revolvers, and can possibility > > rely on the audits performed by third parties (similar to way VPN > providers use third party audits). How does the user > > know the public DNS server has not made false privacy claims ? > > The user gains trust through a variety of non-technical, non-protocol > ways. News items, journalism, company reputation, prefering a non-profit > over an advertisetment company, entity history, people they know, etc. > Perhaps even through third party audits similar to mandated CAB/Forum > audits. Why do I not trust Sony or LinkedIn? Because they proved to > not deserve it in the past. Why do I trust cloudflare or PCH? Because > until now, they have proven to commit to their publicly announced > policies on their websites and as reported by other experts. > I suggest we stick the discussion to technical points, ISPs and Enterprise networks can also publish DNS privacy policies. If you look into the privacy claims from popular public DNS resolvers (see https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements), several claims like client IP address is not treated as PII, client IP address is logged and identifiable data shared with partners may not meet the privacy requirements of the user. > > > I either have a really good DNS provider that I fully trust up my > > sleeve, or I don't. If I do, I don't need the local network one. > > If I don't, I have no choice but the use the local network one. > > > > Local DNS server for several reasons, blocking malware and phishing > > How relevant is this in reality. Linux and OSX people and all mobile > phones do not run anti-malware software. It is very much relevant today, Android and Windows run anti-malware software, and the operating systems are suseptible to several attacks including ransomware, crypto mining, data leakage etc. Several working groups at IETF discuss endpoint and network security (sacm, i2snf, sfc, dots etc.). On a side note, recently malware is discovered on iPhone, see https://blog.malwarebytes.com/mac/2019/08/unprecedented-new-iphone-malware-discovered/ . > Phising happens mostly via > email, which is unaffected by DoH/DoT and can still be done serverside, > No, see https://news.gandi.net/en/2019/07/how-to-fight-dns-hijacking/ > and search engine results - which are curated by both search engines > (google filtering bad stuff) and browsers (eg mozilla preventing me to > go to a known malware site). None of this puts any requirements on my > DNS provider selection. > Several networks today use network security to filter malware, and do not rely on the browser filtering capability. What is the efficacy of these browsers to block malware sites ? > > > , enforce MUD rules to only allow intended > > communications to and from the IoT devices. > > non-mobile IoT devices hardly have a use for encrypted DNS to begin > with, and their MUD profiles should not allow it. Those should clearly > state "DNS to DHCP supplied resolver only" and "these domains related to my > services". Note that this isn't secure unless you could trust the DNS > answers, by either local transport or DNSSEC integrity. > The DNS requests from IoT devices are also privacy sensitive. For example, domain names can be used to identify the IoT device type, make and model. IoT devices would want to use DoT/DoH server capable of enforcing MUD rules based on domain names. > > > Several other reasons like "CDN endpoint selection" are listed > > in https://tools.ietf.org/html/draft-reid-doh-operator-00 > > CDN endpoint tracking is pretty risky from a privacy point of view. The > operator might want that, but the user that desires privacy might not. > The users may desire both privacy and performance, public revolvers like google and opendns support edns-client-subnet. > > > Then why should I ever take a risk that this local network has a > privacy > > policy that does not actually match its implementation? > > > > Firefox falls back to clear text DNS because the local network has > parental control or DNS filtering. Android has an > > option to automatically use to the local DoT server (opportunistic > mode). > > Sure, to support the enterprise/parental case voluntarilly. Again, there > is hardly a need to codify this in XML. An attacker can spoof NXDOMAIN response to the canary domain, and the DNS client will assume the network performs DNS filtering, and falls back to clear text DNS. Further, the client does not know the privacy claims of the network performing DNS filtering, and when the client falls back to clear text DNS, DNS messages are susceptible to pervasive monitoring and spoofed responses. The proposed mechanism allows the client to use the local DoT/DoH server, and avoids the need to fall back to clear text DNS. > Their users are forced to > comply. If I am at starbucks, I am not going to let firefox downgrade me > because of "parental control" desire, whether the instructions are XML > signed or not. > I don't think Firefox prompts the user to decide whether the DNS client can fallback to clear text DNS or not. Anyways, our proposal expects user consent is obtained to use the discovered DoT/DoH server. Further, as discussed in https://tools.ietf.org/html/draft-grover-add-policy-detection-00 it seems network operator can mandate its resolver to be used as a condition of using the network. > > > > Further, it also provides a mechanism to securely signal to the > DNS client that the > > > attached network performs DNS filtering. > > > > You cannot signal securely unless I have a trust anchor already on > my > > device that would be used. If this is a CA-type store of hundreds > of > > trust anchors, I cannot really trust them for this decision over a > > personally selected known safe choice. > > > > You may want to re-look into the Security and Privacy considerations > sections, we are not suggesting to rely on the > > hundreds of trusted anchors on the browser/OS. > > If it is a fundamental design item, it should have its own Section on > how to implement it. Not just waive some Security and Privacy > considerations. > Sure, will add a new section. > > If it is enterprise specific, > > we already have mechanisms in place for securely obtaining updated > DNS > > mechanisms. Like via VPN using RFC 8598. > > > > No, it is not specific to Enterprise IT manged devices. Managed network > security can be provided by ISPs, Home router > > integrated with security service, BYOD policies in Enterprise networks > etc. > > ISPs that are not a utility are defacto an enterprise network. Home > routers are parental control or 'enterprise' networks. BYOD devices > already have their methods to enforce various things on their respective > mobile OS platforms requiring no IETF standards. So your cases are still > really enterprise/parental control, where there are tight and mandatory > trust relationships. No signed XML needed. > As I have explained previously BYOD with MDM is not used in several Enterprise deployments and I have not seen MDM used by Home network security. The proposal equips both the DNS client and user to learn the privacy claims by the DNS server (both local and public) and choose to use the DNS server or not. > > As I said before, I haven't seen much upside on this. I do see downsides > when this kind of mandatory reconfiguring of my device privacy settings > are being forced at the ISP or national level to circumvent my privacy. > I disagree, the draft is not proposing re-configuring the device privacy settings. The client learns the DNS server privacy claims, and decides whether to use the server or not. The intent of the draft is meet the user's privacy requirements, and not to circumvent them. The proposed mechanism also helps the DNS client to automatically learn updates to the privacy claims by a public DNS server and avoids the need for users to periodically manually review the privacy statement. Maybe think of a Human Rights Consideration Section in the document too > as per RFC 8280 ? > I don't understand why the above Section is required in the first place ? If you can propose text, we can evaluate and update the draft. Cheers, -Tiru > > Paul > --000000000000c962230594f0e9ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 10 Oct 2019 at 16:44, Paul Wouter= s <paul@nohats.ca> wrote:
On Thu, 10 Oct 2019, tirumal reddy wrote:

> I am referring to BYOD devices, BYOD will not have Enterprise root cer= tificate and cannot be provisioned with the
> Enterprise DoT/DoH server using AD. The owner of the the BYOD has a ch= oice whether to use the Enterprise network
> provided DoT/DoH server or not.=C2=A0

I have a BYOD device. My enterprise insists that they have limited
control via Google Mobile Device Management. They could dictate
to use certain DNS servers when connecting to certain wifi networks.

No, Enterprise BYOD policy may not mandate MD= M on the device. On the other extreme, Enterprise BYOD policy can mandate t= he MDM on the BYOD to install Enterprise root certificate.
=C2=A0=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Again, this is fixing a problem that I do no= t think exists. Why should I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0trust or not trust this network with DNS to = begin with? Their privacy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0policy update will not change that for me. E= ither, they were already too
>=C2=A0 =C2=A0 =C2=A0 =C2=A0weak for me to trust, so I don't care ab= out their DNS privacy policy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0update, or I trusted them already, in which = case it seems I trust them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more than my own trusted DNS - AKA I'm f= orced to trust them (an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enterprise network).
>
> I disagree, user needs to know whether his privacy requirements are me= t by the local DNS server or public DNS server.

The user cannot know if their privacy requirements are met, with or
without a signed XML statement from those parties.

No, the proposed mechanism conveys signed privacy policy informati= on to the DNS client and the privacy policy contains a URL that points to t= he human readable privacy policy formation of the DNS server. The privacy p= olicy can also be signed by=C2=A0a third party who performed privacy and se= curity audit of the DoT/DoH server.=C2=A0

Most imp= ortantly, user has to select specific networks to learn the privacy claims= of local DoT/DoH server and user=C2=A0
consent is required to us= e a locally-discovered DoT/DoH server. Further, the client can learn update= s to the privacy claims by the public DNS server, and the user does not hav= e to periodically=C2=A0manually=C2=A0review the privacy statement of the DN= S server.=C2=A0 =C2=A0
=C2=A0
The user can only
hope. And since the user can only hope, it is by far safer to pick
a few or a single trusted party, than to hope each time they connect
to a new wifi network.


=

> If the public DNS server decides to change the policy to sell user dat= a to third-parties, the user would want to move
> to a different DNS server.=C2=A0

Sure. But a DNS server that is going to betray the user like that,
wouldn't be stopped by a signed XML file either.=C2=A0
=

The point is the DNS provider becomes liable to penalti= es and will act as a deterrent to lie (similar to the way FTC has imposed f= ine on Facebook).=C2=A0
=C2=A0

> An end-user cannot audit the privacy claims by any DNS provider includ= ing the public DNS revolvers, and can possibility
> rely on the audits performed by third parties (similar to way VPN prov= iders use third party audits).=C2=A0 How does the user
> know the public DNS server has not made false privacy claims ?

The user gains trust through a variety of non-technical, non-protocol
ways. News items, journalism, company reputation, prefering a non-profit over an advertisetment company, entity history, people they know, etc.
Perhaps even through third party audits similar to mandated CAB/Forum
audits. Why do I not trust Sony or LinkedIn? Because they proved to
not deserve it in the past. Why do I trust cloudflare or PCH? Because
until now, they have proven to commit to their publicly announced
policies on their websites and as reported by other experts.

I suggest we stick the discussion to technical points= , ISPs and Enterprise networks can also publish DNS privacy policies. If yo= u look into the privacy claims from popular public DNS resolvers (see https://dnsprivacy.org/wiki/display/DP/Com= parison+of+policy+and+privacy+statements), several claims like client I= P address is not treated as PII, client IP address is logged and identifiab= le data shared with partners may not meet the privacy requirements of the u= ser.=C2=A0
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0I either have a really good DNS provider tha= t I fully trust up my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sleeve, or I don't. If I do, I don't= need the local network one.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If I don't, I have no choice but the use= the local network one.
>
> Local DNS server for several reasons, blocking malware and phishing
How relevant is this in reality. Linux and OSX people and all mobile
phones do not run anti-malware software.

I= t is very much relevant today, Android and Windows run anti-malware softwar= e, and the operating systems are suseptible to several attacks including ra= nsomware, crypto mining, data leakage etc. Several working groups at IETF d= iscuss endpoint and network security (sacm, i2snf, sfc, dots etc.). On a si= de note, recently malware is discovered on iPhone, see=C2=A0https://blog.malwarebytes.com/mac/2019/08/unprec= edented-new-iphone-malware-discovered/.=C2=A0=C2=A0
=C2=A0
Phising happens mostly= via
email, which is unaffected by DoH/DoT and can still be done serverside,
=

=C2= =A0
and search engine results - which are curated by both search engines
(google filtering bad stuff) and browsers (eg mozilla preventing me to
go to a known malware site). None of this puts any requirements on my
DNS provider selection.

Several network= s today use network security to filter malware, and do not rely on the brow= ser filtering capability.=C2=A0
What is the efficacy of these bro= wsers to block malware sites ?
=C2=A0

> , enforce MUD rules to only allow intended
> communications to and from the IoT devices.

non-mobile IoT devices hardly have a use for encrypted DNS to begin
with, and their MUD profiles should not allow it. Those should clearly
state "DNS to DHCP supplied resolver only" and "these domain= s related to my
services". Note that this isn't secure unless you could trust the = DNS
answers, by either local transport or DNSSEC integrity.

The DNS requests from IoT devices are also privacy se= nsitive. For example, domain names can be used to identify the IoT device t= ype, make and model. IoT devices would want to use DoT/DoH server capable o= f enforcing MUD rules based on domain names.=C2=A0=C2=A0
=C2=A0

> Several other reasons like "CDN endpoint selection" are list= ed
> in=C2=A0https://tools.ietf.org/html/draft= -reid-doh-operator-00

CDN endpoint tracking is pretty risky from a privacy point of view. The
operator might want that, but the user that desires privacy might not.
<= /blockquote>

The users may desire both privac= y and performance, public revolvers like google and opendns support edns-cl= ient-subnet.=C2=A0=C2=A0
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Then why should I ever take a risk that this= local network has a privacy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0policy that does not actually match its impl= ementation?
>
> Firefox falls back to clear text DNS because the local network has par= ental control or DNS filtering. Android has an
> option to automatically use to the local DoT server (opportunistic mod= e).=C2=A0

Sure, to support the enterprise/parental case voluntarilly. Again, there is hardly a need to codify this in XML.

An= attacker can spoof=20 NXDOMAIN response to the=C2=A0canary domain, and the DNS client will assume the network pe= rforms DNS filtering, and falls back to clear text DNS. Further, the client= does not know the privacy claims of the network performing DNS filtering, = and when the client falls back to clear text DNS, DNS messages are suscepti= ble to pervasive monitoring and spoofed responses.=C2=A0

The proposed mechanism allows the client to use the local DoT/DoH se= rver, and avoids the need to fall back to clear text DNS.=C2=A0
= =C2=A0
Their users a= re forced to
comply. If I am at starbucks, I am not going to let firefox downgrade me because of "parental control" desire, whether the instructions ar= e XML
signed or not.

I don't think Firefo= x prompts the user to decide whether the DNS client can fallback to clear t= ext DNS or not. Anyways, our proposal expects user consent is obtained to u= se the discovered DoT/DoH server.=C2=A0

Further, a= s discussed in=C2=A0https://tools.ietf.org/html/draft-g= rover-add-policy-detection-00=C2=A0it seems network operator can mandat= e its=C2=A0resolver to= be=C2=A0used a= s a condition of using the network.=C2=A0
=C2=A0
=

>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Further, it also provides a mechanism t= o securely signal to the DNS client that the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> attached network performs DNS filtering= .=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You cannot signal securely unless I have a t= rust anchor already on my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device that would be used. If this is a CA-t= ype store of hundreds of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0trust anchors, I cannot really trust them fo= r this decision over a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0personally selected known safe choice.
>
> You may want to re-look into the Security and Privacy considerations s= ections, we are not suggesting to rely on the
> hundreds of trusted anchors on the browser/OS.=C2=A0

If it is a fundamental design item, it should have its own Section on
how to implement it. Not just waive some Security and Privacy
considerations.

Sure, will add a new se= ction.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If it is enterprise specific,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0we already have mechanisms in place for secu= rely obtaining updated DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanisms. Like via VPN using RFC 8598.
>
> No, it is not specific to Enterprise IT manged devices. Managed networ= k security can be provided by ISPs, Home router
> integrated with security service, BYOD policies in Enterprise networks= etc.=C2=A0

ISPs that are not a utility are defacto an enterprise network. Home
routers are parental control or 'enterprise' networks. BYOD devices=
already have their methods to enforce various things on their respective mobile OS platforms requiring no IETF standards. So your cases are still really enterprise/parental control, where there are tight and mandatory
trust relationships. No signed XML needed.

<= div>As I have explained previously BYOD with MDM is not used in several Ent= erprise deployments and I have not seen MDM used by Home network security. = The proposal equips both the DNS client and user to learn the privacy claim= s by the DNS server (both local and public) and choose to use the DNS serve= r or not.=C2=A0=C2=A0
=C2=A0

As I said before, I haven't seen much upside on this. I do see downside= s
when this kind of mandatory reconfiguring of my device privacy settings
are being forced at the ISP or national level to circumvent my privacy.
=

I disagree, the draft is not proposing re-= configuring the device privacy settings. The client learns the DNS server p= rivacy claims, and decides whether to use the server or not.=C2=A0 The inte= nt of the draft is meet the user's privacy requirements, and not to cir= cumvent them. The proposed mechanism also helps the DNS client to automatic= ally learn updates to the privacy claims by a public DNS server and avoids = the need for users to=C2=A0periodically=C2=A0manually=C2=A0review the priva= cy statement.=C2=A0 =C2=A0

Maybe think of a Human Rights Consideration Section in the document too
as per RFC 8280 ?

I don't understan= d why the above Section is required in the first place ?=C2=A0
If= you can propose text, we can evaluate and update the draft.=C2=A0

Cheers,
-Tiru
=C2=A0

Paul
--000000000000c962230594f0e9ea-- From nobody Wed Oct 16 07:12:03 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 6E90212093A for ; Wed, 16 Oct 2019 07:11:52 -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, DKIMWL_WL_HIGH=-0.001, 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=sky.uk 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 1HI4WvxHqXR0 for ; Wed, 16 Oct 2019 07:11:50 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50064.outbound.protection.outlook.com [40.107.5.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F15F12095A for ; Wed, 16 Oct 2019 07:11:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQHPmc+ndoXFB58ItE+szdL33CWd0Pitx9tsstDauUewqlbtmOoKM27E8jzeEgOmnTVn8jqBSdMlXiel+tzmiURasqukXDR1upsRx9FVdnDiTy4fdPnr83iyd1PuCTZ3O/mxQ+o0JRvieSIRZN6WwCDUXr5xujEi/VtAUkLDLfJ0Ao5oAS7sC9QMWHMYDfau6IU1GFDCa2APIYg7VnszMzleuoclNWSkg+Vki0Ht+T0Aet4sMY86qxc7I+TYiB/K/yDWRKkP7BZmxuDy/qDtlqs58QRq8lzk4d3kh/fbx4J1mninjOv3tapTcjNUQKxdXlSrn6DVltfz23NbZqLahg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoIiRLwpGPq5GoFO+okUej8TFyifodfxQavFDC7nAvg=; b=F4jobG6psUcaNWQXFrYhV3XHs8918z4P9SBlp5jdiC8RSmzxYlUxB3v3Sdvt0Ub/rQpTkJcTC9xp8ALwM8nqIl+wxBCA/zxRXdUGIvxkWmK3ycWLXiWe6ZnuRSI70rP2H4Wwr3d+ytUF2TaHG2i4aogMN0ck8FUDminKbL7KeDSRZWmTaCrDgacZuISAvj/FjJGZGdelSfRwZfaKyF93DNw35Y+le0KCkWpvSeW60DvdFaOn57DWWvkADzrX7EjBFfmgLvzTbpIGKRUE8vHxcBLt6sYU03yAThpFHletHp8JxEwSb/qyxcvsycbkqyG5AFmQ/7fRbBy5++/gW1x0OA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yoIiRLwpGPq5GoFO+okUej8TFyifodfxQavFDC7nAvg=; b=nExfc1mw1b11//EscQrlBCePU2FWlU/97v/XcsnQKecc6pNmgEFaf9jHQULRWuQxC6zF5aqLo45Eaa1vu2pMBtmxw+ykOmjwpEIL7td4vWew+DnuliS2PATfI3llRJ91I8I2rgYWDRW2rIcHUhiAQQMBr30AXr1uG7c4Mdn62q4= Received: from DB6PR0602MB2805.eurprd06.prod.outlook.com (10.172.248.15) by DB6PR0602MB2917.eurprd06.prod.outlook.com (10.172.250.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Wed, 16 Oct 2019 14:11:47 +0000 Received: from DB6PR0602MB2805.eurprd06.prod.outlook.com ([fe80::e11b:ae60:9a47:9890]) by DB6PR0602MB2805.eurprd06.prod.outlook.com ([fe80::e11b:ae60:9a47:9890%7]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 14:11:47 +0000 From: "Dixon, Hugh" To: Dave Lawrence , ADD Mailing list Thread-Topic: Malware C2 non-DNS alternatives Thread-Index: AQHVhCulc5i7hkQa6Ea5mEGFA4P+Tw== Date: Wed, 16 Oct 2019 14:11:47 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hugh.Dixon@sky.uk; x-originating-ip: [151.227.53.111] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29d20b47-b74f-459e-2e90-08d75242c844 x-ms-traffictypediagnostic: DB6PR0602MB2917: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(199004)(189003)(66066001)(14444005)(6506007)(476003)(71190400001)(36756003)(2616005)(26005)(256004)(66574012)(71200400001)(186003)(86362001)(316002)(64756008)(66946007)(66476007)(66446008)(53546011)(102836004)(66556008)(3846002)(5024004)(6512007)(76116006)(91956017)(6116002)(5660300002)(2906002)(110136005)(81156014)(25786009)(305945005)(7736002)(8676002)(486006)(99286004)(6486002)(58126008)(14454004)(33656002)(478600001)(6436002)(8936002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0602MB2917; H:DB6PR0602MB2805.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZXRc0uhB8R3/isq/lpL9z+gtDUdJ1W7P9DRJlfQsw50wFw9ke3t946/zjSI3v7JVPWH9afZPUWlFjckC/zJWwK3G+ewZmwzOv9Bq+ejV1qaS3uhkZVbHz+x+EkNhMa5m4S/EYTIzKEQYUUGy/AG5OsroCcW+4kOcFnqaqrLfChqSLlp7gcIQT3EFQ1gnCzNSiO9VrtFuVvHc4GsJ270K+goqu6PwqBMxX1mkQvzl/LNoZEQTfk6aVNRtUIGAl8f8A1GzEddVHvcO4bgDzLsFcqiUYXjQHeuRMocI2vFhUrctqCrYpVoMJ9Uf7B4lU2LxgnFL+MuFOwISYG0UunAIIwzSavifq8nBhRrh08rWdyZe4v5Xx5zuFUafLgLdiE6pgHZcQouzr9D+dGfN9cZhYMRPEjC1DE2vwomQBUHRnnA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <85D14D88A394434388F0E0CC298591C6@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 29d20b47-b74f-459e-2e90-08d75242c844 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 14:11:47.6125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SXgTlDMzeqAYm8Lco2bFJfdvh85hs3pgd4T1MSkd01O/GuwjEOGVDqNj4p70t8m5i+L4rpR61jw7lNjNvm5t4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0602MB2917 Archived-At: Subject: [Add] Malware C2 non-DNS 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, 16 Oct 2019 14:12:01 -0000 SSBhbSBhY3R1YWxseSBxdWl0ZSBpbnRlcmVzdGVkIGluIHdoZXRoZXIgdGhpcyBpcyB0cnVlIC0N CkknZCBzYXkgdGhhdCB0aGUgcmVxdWlyZW1lbnRzIGFyZSBmYWlybHkgaGVhdnkgZm9yIGEgcmVh bGx5IGdvb2QgbWFsd2FyZSBDJkMgcHJveHkgKHdoaWNoIGlzIHdoYXQgRE5TIGlzIGRvaW5nLCBy aWdodD8pDQoNCi0gYW5vbnltb3VzL3VuYXV0aGVudGljYXRlZCAoZS5nLiBub3QgbGlrZSBhbiBB V1MgaW5zdGFuY2Ugd2l0aCBhIHNodXR0YWJsZS1kb3duIHVzZXIgYWNjb3VudCBhbmQgcG90ZW50 aWFsIHRyYWNlYWJpbGl0eSkNCi0gZ2xvYmFsbHkgZGVwbG95ZWQvYXZhaWxhYmxlDQotIHdpdGgg YXV0b21hdGljYWxseS11cGRhdGVkIGNvbmZpZ3VyYXRpb24gKHN0cmFpZ2h0IGJ5IG1pc2NyZWFu dCBhY3Rpb24pDQotIGhpZ2hseS1zY2FsZWQNCi0gdHJhZmZpYyB0eXBlIGFscmVhZHkgdmVyeSB2 ZXJ5IGNvbW1vbiBpbiBhbGwgbmV0d29yayBlbnZpcm9ubWVudHMsIHdpdGggMjQvNyBhY3Rpdml0 eS4NCg0KQW55IG1vcmU/DQoNCkgNCg0KT24gMDkvMTAvMjAxOSwgMjA6MjUsICJBZGQgb24gYmVo YWxmIG9mIERhdmUgTGF3cmVuY2UiIDxhZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg dGFsZUBkZC5vcmc+IHdyb3RlOg0KPHNuaXA+DQpJdCdzDQogICAgbm90IGJlY2F1c2Ugb2YgYSBs YWNrIG9mIHBvc3NpYmlsaXRpZXMgdGhhdCBhcmVuJ3QgdGhlIEROUy4gIEknbSBzdXJlDQogICAg YSBub24tdHJpdmlhbCBudW1iZXIgb2YgcGVvcGxlIG9uIHRoaXMgbGlzdCBjb3VsZCBjb21lIHVw IHdpdGggc29tZQ0KICAgIG5vbi1ETlMgbWV0aG9kcyBwcmV0dHkgcXVpY2tseS4NCiAgIDwvc25p cD4NCg0KDQpJbmZvcm1hdGlvbiBpbiB0aGlzIGVtYWlsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMgbWF5IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZXhjbHVz aXZlbHkgZm9yIHRoZSBhZGRyZXNzZWUuIFRoZSB2aWV3cyBleHByZXNzZWQgbWF5IG5vdCBiZSBv ZmZpY2lhbCBwb2xpY3ksIGJ1dCB0aGUgcGVyc29uYWwgdmlld3Mgb2YgdGhlIG9yaWdpbmF0b3Iu IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uIFlvdSBz aG91bGQgbm90IHJlcHJvZHVjZSwgZGlzdHJpYnV0ZSwgc3RvcmUsIHJldHJhbnNtaXQsIHVzZSBv ciBkaXNjbG9zZSBpdHMgY29udGVudHMgdG8gYW55b25lLiBQbGVhc2Ugbm90ZSB3ZSByZXNlcnZl IHRoZSByaWdodCB0byBtb25pdG9yIGFsbCBlLW1haWwgY29tbXVuaWNhdGlvbiB0aHJvdWdoIG91 ciBpbnRlcm5hbCBhbmQgZXh0ZXJuYWwgbmV0d29ya3MuIFNLWSBhbmQgdGhlIFNLWSBtYXJrcyBh cmUgdHJhZGVtYXJrcyBvZiBTa3kgTGltaXRlZCBhbmQgU2t5IEludGVybmF0aW9uYWwgQUcgYW5k IGFyZSB1c2VkIHVuZGVyIGxpY2VuY2UuDQoNClNreSBVSyBMaW1pdGVkIChSZWdpc3RyYXRpb24g Tm8uIDI5MDY5OTEpLCBTa3ktSW4tSG9tZSBTZXJ2aWNlIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBO by4gMjA2NzA3NSksIFNreSBTdWJzY3JpYmVycyBTZXJ2aWNlcyBMaW1pdGVkIChSZWdpc3RyYXRp b24gTm8uIDIzNDAxNTApIGFuZCBTa3kgQ1AgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiA5NTEz MjU5KSBhcmUgZGlyZWN0IG9yIGluZGlyZWN0IHN1YnNpZGlhcmllcyBvZiBTa3kgTGltaXRlZCAo UmVnaXN0cmF0aW9uIE5vLiAyMjQ3NzM1KS4gQWxsIG9mIHRoZSBjb21wYW5pZXMgbWVudGlvbmVk IGluIHRoaXMgcGFyYWdyYXBoIGFyZSBpbmNvcnBvcmF0ZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMg YW5kIHNoYXJlIHRoZSBzYW1lIHJlZ2lzdGVyZWQgb2ZmaWNlIGF0IEdyYW50IFdheSwgSXNsZXdv cnRoLCBNaWRkbGVzZXggVFc3IDVRRA0K From nobody Wed Oct 16 11:29: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 27ADF1201EF for ; Wed, 16 Oct 2019 11:29: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, SPF_HELO_NONE=0.001, 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=comcast.com header.b=vWDTL/Q8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=pxJ9Luvq 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 ZbrkYfRjZaKE for ; Wed, 16 Oct 2019 11:29:27 -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 1861A120116 for ; Wed, 16 Oct 2019 11:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1571250566; x=2435164166; 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=/PDqAwtRUasGzayzTt8onQGbQvEK+IVhR4nO4uxOH8I=; b=vWDTL/Q8UE/bbyCUnK3LLyiBroC4tnR+MTYyUMIdlF+WS4g5D9Jfjr2uMVkN9fCv 4khjwfS+JIWekNGUdWzpvvSOHjrC7yxlMuJS4YZYSvovqOOiJ55JLeejzXr6fY+y ZzSqRwUBr046z/4DCzp+vaCf9jUW6Gz8sb94eIevbGbt/NEEFcPA5ESiQpuePOwS wu3DKNz+B8hluTZewyJseZsXlPInMeL8W3rqfuAM0M2NUhrzNLLtmY5PjjfHpSK0 ULRFF8aLdDH5rs0z3F/2yuNHnfL/wNI27kTi41tHSLKpG5Hos251/6WYj9WSxJN3 6ENS6aSC9yqvB/H+H1TPng==; X-AuditID: 60729ed4-38dff7000000b133-98-5da76186b73e Received: from COPDCEX13.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 3F.73.45363.68167AD5; Wed, 16 Oct 2019 12:29:26 -0600 (MDT) Received: from COPDCEXC36.cable.comcast.com (147.191.125.135) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 12:29:25 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEXC36.cable.comcast.com (147.191.125.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Wed, 16 Oct 2019 12:29:25 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.59) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 14:29:21 -0400 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4196.namprd11.prod.outlook.com (10.255.89.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 16 Oct 2019 18:29:12 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3%7]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 18:29:12 +0000 From: "Livingood, Jason" To: Eric Rescorla , Barry Leiba CC: ADD Mailing list Thread-Topic: [Add] Proposed charter and BoF request for IETF 106 Thread-Index: AQHVfnSyY2vPTBzSskOC+ZEhrPLmqadSNM6AgAsqb4A= Date: Wed, 16 Oct 2019 18:29:12 +0000 Message-ID: <6E28E5E0-0857-45D6-8117-46880556A819@cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jason_Livingood@cable.comcast.com; x-originating-ip: [50.225.119.196] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cccd8a3f-ed73-46bb-a87e-08d75266be33 x-ms-traffictypediagnostic: BY5PR11MB4196: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(136003)(366004)(39860400002)(346002)(199004)(189003)(99286004)(81156014)(486006)(6486002)(8676002)(6436002)(186003)(6512007)(7736002)(76176011)(66476007)(66556008)(91956017)(64756008)(6506007)(66946007)(66446008)(66066001)(81166006)(8936002)(76116006)(2616005)(476003)(446003)(11346002)(6246003)(86362001)(229853002)(478600001)(25786009)(4326008)(3846002)(6116002)(102836004)(33656002)(71190400001)(256004)(316002)(58126008)(14454004)(305945005)(26005)(71200400001)(110136005)(5660300002)(2906002)(80792005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4196; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u4bZhHmvOquWAe5HwA9W2exXlq6QVr2Myac3z4bvDpLGKYQ/0oiO/l44iVKY8JuyKuEIzx+iJqbm7xY9mlACHaQzBAH5rJSU+dfLsZAiET7T2cBJYKubplNUbsCu596nySMm63t/zuvHozEjym9XWNg1SdKrihZ0RpolFnU0g0eFOWAi+y+KLhXgxppNqcirGx9DfKMHVTOT8JFxIfSrRJLRHNcf8JijXxCRK8W/zKAJJueceQRX8fFVWsN6sf/6AMvQojV29SuA/WxEf83pmgOze7bsa/+kw6tnx9l4iK+xfHTolFuANUhRLXCVsWbKelAzwTZQtg1oKevTDI213uA21KTdAZiGeTJwmR0+cDUV5OvdW4QAOm9hZWoP6QOvb5PDPjyUAqL/mPKU1dYi3tl/KKUuZYVrBwIbCW/ljso= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aMg8sgxS6EMKm6NqnbbjfoGptJKRxtxtMjXJ3nqS0c1bVbtF2AKORamCA0ZBNx4h6Mm49UjQAxD+5UDzn1zvo1eEpNJKxKskldni2lnOEe3cZUmezmhdHQtTrG1RUpHbU06WOmikxVxuGlKjKzYzCdIJXSg7gi84Ez6o0GZz29vGX3FSssWz5h1wlboFuA0N3IE0QS5T2mEsBnPxIYZWKt1YAK2NLvEq1hS65Gmus8mNslRuAoPxcVS4BGBoZy01LbH9PhkeAP/kPMPTcZVzW2govbC0Gs7KKxK+yJ+StkovGPo5paMpaPc4NNqnijuXbHvfSAfGi72kuWkQB5H7kQ== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vvEURzIWwVD4xE7s08syNFYbltF7gqVwb35n6sbMo5Q=; b=kHuikeh5End17+4Fh5+EeOmRSO3gC5J9yYYEI3uvS61h7fzkFQSQzqFRnaL30xPUKrxkMJZIgm1KyiHN6etnMfrhmgKEWhjcNEr9qOISQe5aNn/dyBe5d194ollUlLqNFv6V1vuVGM7FS2+51rl05g+CIdmg/gN596mZ12CPnamcJAR2gV9OtBHbDynHRXQJTa3f7umITa7qtcT7HuALGV9jNaoAEWBy73VzU5k2gn3DUmAMxS8qEJybI3mgmpXdwdCcyexBmQ15Ao586gU7sZSi6r70lcMULFV9ak/s+0x+qDxS/CXY6mUztAc2J81hBu2xY9XtpyLTOe8VvHyggg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector2-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vvEURzIWwVD4xE7s08syNFYbltF7gqVwb35n6sbMo5Q=; b=pxJ9Luvq7YKPZCZ4yHGizSksHk8IfAaLchnF/AB3NaxVVIrfpCWi0xaeveryy62B5lSysAUQjKztDsMyRDcfC8wRsra7M1St2iKWM2dylinF6MeNJTgCYkoWKTTa7/XPP2gKTBUXZdesMz3LkPbcEPYR/tjaMQklgjK6+BzJw5A= x-ms-exchange-crosstenant-network-message-id: cccd8a3f-ed73-46bb-a87e-08d75266be33 x-ms-exchange-crosstenant-originalarrivaltime: 16 Oct 2019 18:29:12.5314 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: XOkM5Z0eFNZ/4i61+4dmlTDUZ8FUt4meI+yZM4bCN/qScbAucS8MTNPryuC0QZyaIdK4yx+aSfGRpniMFhmj3G0CqaHG6361WAao7OGt6f8= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4196 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <3CB511FD30F2A345ADA78A37EDDC632E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22Se0hTURzHO/fublfb1nFq/rICW0Qmqc0XM8wstEZgpn+JtNoVj2nOWXdm alCzhtVE7KFo5qt8lY8MgwgTEmfZAxVMgyyTciERvSh6ouXdXRDk+etzvr/v+b04LK2ySn3Z TFMu4U2cUS11lxj4mvOBxVyrfsPF63Lt70fXpNr+xlFGe+XtsCyG1lnbSmldU9MPSnd+upje RadYUFRuBk+43FiSTkxmEu3u99+JSiXpOTyJ43hjQRIxEm5hm+BMI8bMPMIHL5gmeME8BhuV UWudkh4YUOZPPe9jLKhcaUMsCzgM5lpkNuTGqrCdgq7PZhcjuP061Ibc57mWgl83L1Li5T6C IWuzTLyco2CiqFsqPnmF4FNzpMBSHAGTl8Zogb3wduiyP6EEpvFqsDomnbonjoHmnjJK6MIL b4FTHzxF+0YYG/rCCLIErwFrVbIgK3As3Pv5kRIrVSKYaQ8X2A0nwp3pQecACC+Fbw87XJV8 YMJR72TAGJp6R2iRveHN9JwzvTcOhqrJAPFpGjTaLrvsajjZWi8TeSWM1pcgkePheHWXROQA OD4x7fJkwTNHhUtfC9ZPdYzIK+BsRQkjbArwCAOlfbXOaVV4P7wbjz6Dwqv/6bR6PkLjddDV EyzKOnjRUk6JvArKS17Kqp2L8IAHFxySBsS0IWVkRJBGExakCdcGhWhCupHzb9aN3UKPK3X9 CLNILVcs2tGqVzFcnrkgux8BS6u9FPXWJr1KkcYVFBI+Zy9/yEjM/Wg5K1H7KJSdDXoV3sfl kixCDhD+b5Ri3XwtaOvpo7tvbEqM51lb59O4gW2OJwlHPLanjcu7yyUeD2fXh14rW1bcd2an aTjOM9M/7CuTPqNrK/rqltRTUzt7V96x2eBI3ZB68EPgiWy/EzMVvYqU3apjbYMdV+3SQiyJ lcdjw/f2qPf5tHax5f5hy7vQcFmyXb+nNyVhidK/BYWpJeYMThNA82buDxApa4WXAwAA Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 16 Oct 2019 18:29:29 -0000 QSBmZXcgaW5saW5lIHJlcGxpZXMuDQoNCj4gRnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCj4gVGhlc2Ugc2Vl bSB0byBiZSBvbiB5b3VyIGxpc3QgYmVsb3cuIEkgdGhpbmsgd2Ugc2hvdWxkIHN0YXkgYXdheSBm cm9tDQphbnl0aGluZyB0aGF0IGlzIGFib3V0IHNwZWNpZnlpbmcgYmVzdCBjdXJyZW50IHByYWN0 aWNlcyBiZWNhdXNlIGFzDQpmYXIgYXMgSSBjYW4gdGVsbCBhbGwgYnV0IHRoZSBtb3N0IHRyaXZp YWwgb25lcyAoaGVyZSBpcyBob3cgdG8gc2FmZWx5DQpydW4gYSBUTFMgc2VydmVyIG9yIHNvbWV0 aGluZykgYXJlIGNvbnRlc3RlZC4gRm9yIGluc3RhbmNlLCBldmVuDQpyZXRlbnRpb24gcGVyaW9k IGhhcyB2ZXJ5IHN0cm9uZyB2aWV3cyBvbiBib3RoIHNpZGVzLg0KDQpbSkxdIEZhaXIgcG9pbnQg dGhhdCB0aGVyZSBtYXkgYmUgc29tZSBpc3N1ZXMgYWdyZWVpbmcgb24gQkNQcy4gT24gdGhlIG90 aGVyIGhhbmQsIGFzIGFuIG9wZXJhdG9yLCBzb21lIGNvbnZlcmdlbmNlIG9uIGFuZCByZWNvbW1l bmRlZCBiZXN0IHByYWN0aWNlcyBtYXkgYmUgcXVpdGUgaGVscGZ1bC4gU28gSSB3b3VsZCBwcmVm ZXIgdG8ga2VlcCB0aGlzIGluLCBhbmQgbm90IHNoeSBhd2F5IGZyb20gZGViYXRlIG9uIHRoaXMg YmVjYXVzZSBJIHN1c3BlY3Qgd2UgbWF5IGV2ZW50dWFsbHkgZmluZCByb3VnaCBjb25zZW5zdXMg aW4gc29tZSBhcmVhcyBhbmQgdGhvc2UgY291bGQgYmUgcHV0IGluIGEgQkNQICh3aGlsZSB0aGUg b3RoZXJzIHdoZXJlIGFncmVlbWVudCBpcyBsYWNraW5nIHdvdWxkIG5vdCkuDQoNCj4gVGhpcyBs aXN0IG9mIHByYWN0aWNlcyB3b3VsZCBiZSBtdWNoIG1vcmUgYWNjdXJhdGUgaWYgaXQgaW5jbHVk ZWQgdGhlDQpyZXNvbHZlci1sZXZlbCBETlMgcHJhY3RpY2VzIHRoYXQgd2UgYXJlIHRyeWluZyB0 byBtaXRpZ2F0ZSB1c2luZyBEb0gsDQppbmNsdWRpbmcgTlhET01BSU4gc3ludGhlc2lzIGFuZCBj b2xsZWN0aW9uIG9mIHVzZXIgYnJvd3NpbmcgaGlzdG9yeQ0KZGF0YS4NCg0KW0pMXSBObyByZWFz b24gd2h5IE5YRE9NQUlOIGFuZCBvdGhlciBzdHVmZiBzaG91bGQgbm90IGJlIGluIHNjb3BlLCB3 aGV0aGVyIGFzIHBhcnQgb2YgZXhwcmVzc2lvbiBvZiByZXNvbHZlciBwb2xpY3kgb3Igb3RoZXJ3 aXNlLiAgQSBsb3Qgb2YgdGhpcyBpcyBvcGFxdWUgdG9kYXkuIEFzIHdlbGwsIHByYWN0aWNlcyBh cmUgbW9yZSBpbiBmbHV4IG5vdyB0aGF0IHBlcmhhcHMgaW4gdGhlIGxhc3QgMTAgeWVhcnMsIHNv IEkgdGhpbmsgd29yayBoZXJlIHdvdWxkIGJlIGludGVyZXN0aW5nLg0KDQoNCg0K From nobody Wed Oct 16 11:35: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 19BC91201EF for ; Wed, 16 Oct 2019 11:35: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, SPF_HELO_NONE=0.001, 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=comcast.com header.b=gFGDGdIo; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=CA6dXgq6 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 WTpDUGntDchg for ; Wed, 16 Oct 2019 11:35:28 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 6110C12093C for ; Wed, 16 Oct 2019 11:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1571250894; x=2435164494; 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=2DzIdDcakXz2r9HQen9OvANLwZAjRoalXGiRYgtJNao=; b=gFGDGdIo7CcNg9eEv+3S6lno7yM+K3cp7NoPp3KkWOG7qU4zpfu//fTL/LxK/rmH TTLn4DLUhoMYSJgJOfiNal6phQmSWYt+/CajLMwifRqenZZu/FI7KxjmwbCjH+6z qnNfEdcEQzJrWHHnkAyvoRNjmIzz3i4ewxk5HAQyqY2jcpWSOU3OVfW814R8gbck u+wmkGl3EFlQrfePU+ChgJ3YcU1ayoCgWZVZF5KI6ikQy9tdEhUTFLCZ139juqWx zbVAMFB5oOSDxkRsN00z+hHuy2wGwqCFYmbCRPl2e+Osa/fqyVTrXPXPUPn8Iajc lW1zUjTr5bRAdntsUvUaBQ==; X-AuditID: 60721c4b-8fbff7000000be6c-91-5da762ced101 Received: from PACDCEX48.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id C0.BF.48748.EC267AD5; Wed, 16 Oct 2019 14:34:54 -0400 (EDT) Received: from PACDCEX46.cable.comcast.com (24.40.2.145) by PACDCEX48.cable.comcast.com (24.40.2.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 14:34:54 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX46.cable.comcast.com (24.40.2.145) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 16 Oct 2019 14:34:54 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.57) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 14:34:47 -0400 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4196.namprd11.prod.outlook.com (10.255.89.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 16 Oct 2019 18:34:42 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3%7]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 18:34:42 +0000 From: "Livingood, Jason" To: Eric Rescorla , "chris.box@bt.com" CC: ADD Mailing list Thread-Topic: [Add] Proposed charter and BoF request for IETF 106 Thread-Index: AQHVfnSyY2vPTBzSskOC+ZEhrPLmqadSNM6AgAAf+jyACwv+AA== Date: Wed, 16 Oct 2019 18:34:42 +0000 Message-ID: <92DEFE79-4B08-4043-A45E-289EFBD1D2E3@cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jason_Livingood@cable.comcast.com; x-originating-ip: [50.225.119.196] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0da122ea-cb04-4ab3-1f29-08d7526782d6 x-ms-traffictypediagnostic: BY5PR11MB4196: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39860400002)(376002)(366004)(136003)(396003)(199004)(189003)(102836004)(6116002)(3846002)(256004)(71190400001)(33656002)(2501003)(478600001)(4744005)(25786009)(4326008)(5660300002)(80792005)(2906002)(14454004)(316002)(58126008)(110136005)(305945005)(26005)(71200400001)(7736002)(6512007)(186003)(6436002)(66066001)(64756008)(91956017)(66556008)(66476007)(76176011)(6506007)(66446008)(66946007)(486006)(99286004)(81156014)(6486002)(8676002)(11346002)(476003)(2616005)(446003)(229853002)(86362001)(6246003)(76116006)(81166006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4196; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TGx0T8ja6zgJzVNPt1iaxcSonTfxW1fmj66Eze5nsLhulo/XzfOpKq6zgEHvbrCI9nBUQkfeBiLSllez2s++/Tc3BH37BEBoaZvMC+sZK9XdoufyfzkOQSRpLtVK986v/8lU9+ckUYsR+kOBN87jT48zo/SxGOznl/0d33JXZC8VhbxV0bchsrqt0YyMZqGW/xpfzUoU3oVknVjJtAnYJHsvJszNUnFtHECYlm7sCAaTBj4jH6e/IDG/1RU6sc9U8n7KFs5P5sLWh24qtl/mFGpHAV3aGUfkxpC0PjMWXdY/wrVtEKmxxpzr0VZcyQo6BYMw/Z4iK9Lk8iTV/9l53B9wMQiD9eG1hIAm2gkybTPa5qv7cSsMyO/6Sp96wFQf0CKG/oYMQb0Q0y7siAKPNYytFLFcCEW1ycTbo/EM+zc= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BdB9lA/GX4tmiIPh/a+KlxKh59Xune/0XfwPJsLGPyEt4bfMe0XXzk6ztyHPYDKWxNIPoIhcbmTx6w+hXp/ZS+Lkv56uL/5N7yYGmQwKHS3s+d0Una4084O0FoPwZUKjc+G/q4H86uqRQeWflafeGfAtgV4jCPnS/+dykGooB2cilHKyWacdj/CG1zB5ut6BcRY+tcsVK2f57lgtRz9v463T+sSj74oNO+84QpCJDGcAfmc8Tt35Z0buODYIAJM/uGQDZLrivRFsO1O4H1e38WLMmyDjL3rZB7BDnAUiAYHIDnpxZppcTw1HUkdMf3nrhe3cuHADYKey+YfQxBMY2A== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PJcsk0AvC0/UfAcJQvvddWXPDtXynw8pZc7looPCtB0=; b=O1cW2uO7bcqVCQ08N+UCdyo9wIewt1zmPJYJ4JOSidR8hPc6bS9zcPnSXi9gpc8Bx8tBXmEBXlDodul+zRVdxfEl/q1RowvOMNxNBWnxv5UNBG/B5/xETCGvqEM5YDAblRvohEHz+cy/HbvWmn3x93qFdyAI4HIrpWFOx/zge01YfhN1PMT+0gWT8aXTy/9gSgQ/aVTpISDjMktNTa4BowYg61CnP+11JF0wYSpsWmoOT+7EHnmHJgIR19XzoJZ6zc5fRl2pTL7fLv6P0/1JbV3i9N2qbfsMTEQmZwg3G2m49AbHZGau1nlSgbwW7eBnIx7mtIMEtbuR+xHnN6obqw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector2-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PJcsk0AvC0/UfAcJQvvddWXPDtXynw8pZc7looPCtB0=; b=CA6dXgq6QO3IvKiOvzEWgikXoSm4HQVgaJHAc8JYbUGnsg68UODLInN6VvQBg4BgkBvImtaIjFeKPPRvMhmQsOBGM7882yv24a1/a3TeRpsYWABzQXhiZmFgU8zWqs0eaiK6Bwm9oySLlfEzXJatCZx22UsdUN4jnm+HGVCKYKA= x-ms-exchange-crosstenant-network-message-id: 0da122ea-cb04-4ab3-1f29-08d7526782d6 x-ms-exchange-crosstenant-originalarrivaltime: 16 Oct 2019 18:34:42.4785 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: dBlkOgK1VsrPM95/tdbvds05wy057T4BxdxZgSEIM00MXefo8aobJ5RmLpVo54xxZ40wRmXigvej3h8MgC0ND5BDAjdp0tNWERTfcz0Vb7I= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4196 x-originatororg: cable.comcast.com 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+NgFmpnk+LIzCtJLcpLzFFi42JJKPa00D2XtDzWYNEqZYv/p9exWSx9vZzZ YsXrc+wOzB5tXyYzeSxZ8pPJY/LjNuYA5qgGRpuSjKLUxBKX1LTUvOJUOy4FDGCTlJqWX5Tq mliUUxmUmpOaiF0ZSGVKak5mWWqRPlZj9LGak9DFlHHg/HPGgmPsFX8O32FsYFzD3sXIySEh YCKx9ugqli5GLg4hgYNMEj2vTjNDOLsYJZp2/mGFcK4ySsydsAQqc5RRYtOJ2+wQziQmiT+H FkFlHjFKNMxeyAgymU3ATOLuwivMILaIgLvE9pcQNrOAskTLk7tgtrCAg8TSXf1MXYwcQDWO Eh3vhSFMJ4lzl6VBKlgEVCXWbn0AVs0r4CLx/dcUJohVG5gklk59zwKS4BQIlFjzcgvYQ4wC YhLfT61hglglLnHryXwmiEcFJJbsOc8MYYtKvHz8jxVkl6iAvsSMu1oQrSkSi7sWQZUrSbQv nw8NI1mJS/O7GSFsX4l/tw9A1WhJNN16DFWTLXHr41eoGjWJG286oFbJSEyc2g0ORQmBh6wS 2yb/YQHZKySQJfH2qt0ERtNZSC6dBZRhFtCUWL9LHyLsIXFgyidmCFtRYkr3Q/ZZ4JAQlDg5 8wnLAkbWVYw8lmZ6hoYmekYWeuammxhBybNIxnsH47qf7ocYBTgYlXh4gzyXxwqxJpYVV+Ye YpTgYFYS4Z3fsiRWiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+/NQtihQTSE0tSs1NTC1KLYLJM HJxSDYzH//UL1q9QUt9ltXi7sf6yMk8rzyLRR1WfLZmUXcvcpos5ie3cdP3ssjqVd5OnCspx 5b1scH+QmrFx+orSksmy5pv5/VxStnt0pPjpskxVMFN+Zteo2hgmZFiXv9V6/vnS/I01x03+ VSY2yS10ylOtsPIRqS+SEYr8WvQ6yizwKJOVXf16JZbijERDLeai4kQAz2Z5kZoDAAA= Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 16 Oct 2019 18:35:31 -0000 PiBGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPg0KPiBBcmd1aW5nIG9yIG5vdCwgaXQgY29udGludWVzIHRvIGhh cHBlbiwgYXQgbGVhc3Qgb24gVC1tb2JpbGUuDQoNCltKTF0gUGVyaGFwcyBhbiBpbnRlcmVzdGlu ZyBxdWVzdGlvbiB3aWxsIGJlIHdoZXRoZXIgc3VjaCBvcGVyYXRvcnMgd2lsbCBzdGlsbCBiZSBk b2luZyBOWERPTUFJTiByZWRpcmVjdGlvbiBpbiAxIHllYXIgb3IgNSB5ZWFycy4gSSB0aGluayB0 aGUgQ0NQQSAoQ2FsaWZvcm5pYSBDb25zdW1lciBQcml2YWN5IEFjdCkgYW5kIHN1YnNlcXVlbnQv cG90ZW50aWFsIFVTIHN0YXRlIGFuZCBuYXRpb25hbCBydWxlcyBjb3VsZCBpbmZsdWVuY2Ugc3Vj aCBwcmFjdGljZXMuIEFzIHdlbGwsIHRoZSB3aG9sZSBkaXNjdXNzaW9uIGFuZCBkZXBsb3ltZW50 IG9mIERvSCBpcyBhbiBleHRlcm5hbCBlbnZpcm9ubWVudGFsIGluZmx1ZW5jZSBhcyB3ZWxsLiBT byBteSBpbXByZXNzaW9uIGlzIHRoYXQgdGhlIHNpdHVhdGlvbiB3aXRoIHJlc3BlY3QgdG8gdGhl c2UgcHJhY3RpY2VzIGlzIGxpa2VseSB0byBiZSBsZXNzIGNlcnRhaW4gdGhhbiBpbiByZWNlbnQg eWVhcnMsIGFuZCB0aGUgZ2VuZXJhbCB0cmVuZCBzZWVtcyB0byBiZSBhd2F5IGZyb20gc3VjaCBw cmFjdGljZXMuDQoNCg0KDQoNCg== From nobody Wed Oct 16 11: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 EC706120116 for ; Wed, 16 Oct 2019 11:42:46 -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, SPF_HELO_NONE=0.001, 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=comcast.com header.b=FVenhrY1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=BMb45+hI 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 T5Mw1QtRLAWX for ; Wed, 16 Oct 2019 11:42:45 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 303851201E5 for ; Wed, 16 Oct 2019 11:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1571251364; x=2435164964; 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=4Mm4uUivpLUCnJ7mjKMs7UVtdj2NuZ88LhUREDqnPdI=; b=FVenhrY1HyeLMpJBzRXgzE8vm2mcwMOeDJBGgNHJX+XSINSboisnHFMq4I7c6w/d u6+yWOIij6QmfaxegbffnNrMNDLZO6tnb1Df0gUD2foiSFwkgffpjrc2oh4jTLJD apBaXTcxKLyLQ5fL4JQb9MP44ASRNicgUexpoUzindKzZgRvQykNRfmFjQnmuu0u NECqgk1FEpxoJ4PBWyCVyXqUYUu9EjkjFR/KcPlI/OOuO5kzfrBncA+Ss4IV9tfW uunwH7pH2mbKvhzwHj1KBz06NiGGFxIwRmhjLIq5kixlABux8WJPpLW/cXHlTmrQ c6/Dd5xn0uYv5+LSZQdjXA==; X-AuditID: 60721c4b-8e3ff7000000be6c-4d-5da764a4982f Received: from PACDCEX56.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id AA.50.48748.4A467AD5; Wed, 16 Oct 2019 14:42:44 -0400 (EDT) Received: from PACDCEX40.cable.comcast.com (24.40.2.139) by PACDCEX56.cable.comcast.com (24.40.2.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 14:42:43 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX40.cable.comcast.com (24.40.2.139) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 16 Oct 2019 14:42:43 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.55) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 14:42:35 -0400 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4241.namprd11.prod.outlook.com (52.132.255.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 16 Oct 2019 18:42:30 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::6427:b4f4:6f10:9ed3%7]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 18:42:30 +0000 From: "Livingood, Jason" To: Richard Barnes , "add@ietf.org" Thread-Topic: [Add] Proposed charter and BoF request for IETF 106 Thread-Index: AQHVfnSyY2vPTBzSskOC+ZEhrPLmqadSNM6AgABNxZGACuBgAA== Date: Wed, 16 Oct 2019 18:42:30 +0000 Message-ID: <7330B585-68C9-4706-952F-E83A5604FC86@cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jason_Livingood@cable.comcast.com; x-originating-ip: [50.225.119.196] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f3d40ca-d1c4-4e94-26ea-08d7526899af x-ms-traffictypediagnostic: BY5PR11MB4241: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(80792005)(4744005)(99286004)(26005)(7736002)(33656002)(6512007)(8936002)(6486002)(25786009)(2501003)(76176011)(6506007)(2906002)(229853002)(186003)(6436002)(102836004)(11346002)(8676002)(58126008)(14444005)(2616005)(71200400001)(86362001)(76116006)(478600001)(71190400001)(256004)(81156014)(446003)(66446008)(110136005)(66556008)(305945005)(64756008)(66066001)(316002)(66476007)(91956017)(6116002)(476003)(66946007)(14454004)(5660300002)(81166006)(486006)(3846002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4241; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fnog2924BbycSX5xj/VDw8xJ6FuPJPMv48CTrV+DHqI0SLNOb3wwuAE6VVopjrzg5fjLTB/ydvazGCOoxTHAJhRLwMMfSZyGZKF2HXKMN4xq69kGcpxIDKGy75mbBzOCl/jpvGdqr6wXAevYdkf4gSFhvJAhbwgS7ei4ELdyCVU757uBpTm5YhxXEb6xaoXFpJQmYkofFJ7kw0Dfi5NPj6TcFZzepjPhnE6x7Akkn+PmVdd9dBf9zYBCDlKUGNmikul8/mTrVBcuQ5jLMifgBspVUjuAHTnFWcy7R1X/EgexNF6kS7nPhIyFSDe50PkWdy5D8+qrTDpgYsSXJBo7ji3Y9rZX1IopiL6BFn1XMDr9yQ+fNA9tb/R9cPhDuD4GFQ/1C5MbkCtWL5y9cGA98EE3LMeWSH3i6fxe6MRDjjU= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JkvsNqO9u7t3THtyyeZDoyIx/cHINPC+1bsBwthLWyOZKYeI3SKbiRfbfCzmKG4ZO2UboJIsD+nlHeMZiNLq3lMdWpHzisn0JzeBzwoSldJTYDzmDUIt2SlGED3X9nzHZ0V0EpqsPX+tANHZM3dK3CMG1iwsxgUISnYrxKHr65kKWMyUy+k+b4KpIqMCvCTyl8A46ifiovCKw5fI2ucYcEsjbdquw0tusv58OXKlaVAMM+zQERcwG4EFgRhwwdx+9fZT8gOHu7xmqCMQlHp4B/oRqKB9hd9sg1m9EIl2BIrqGf6YRGY3zFT/5Yf8IsWmg5/BtkQpHxoDqtTXe4WF5Q== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I2lCT/E39/s3tHLfTKppBLCP8TCA7fXEGjzdLNKq6Zs=; b=WtSfJ27QkwajuewLDyJf0R5tNQj7uUMuQA7STAnV23oHdFBAQE4M7wzUnliOEMoCAE6+A966kYhv8duI5dzKlcJgocwk0ewKzb/YzWebP9BG23G6oWwEgXINsbswKTy7zR4S+NSNVYhi4ZGi6917QxL2myUor265HXNXo7RgSUfP/ekjT2qWQAzeiO1/EKksjy9oX663sI/08P4n9gsHYHckp1f6Bv2zYYG0Ew46xVMaYn3cps/PF8gdQQFAbLSD1OZScXZSBBwVHZfxEvjbl/djPdJDMwaWiT6kdlHKRxOdjvqxpr1nVZ26yku5AaFY1h+hj9QPPTQwGu3PbPK/XA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector2-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I2lCT/E39/s3tHLfTKppBLCP8TCA7fXEGjzdLNKq6Zs=; b=BMb45+hINKm/q3UZ3EdSiVpHQo8HlEMMLqQBLWdLLLhrNiG0pT+4Z3N87hDVJAhWcJ+ImTseszuFcKhY8VKy/VBUWJaG8dFywvC4f8ZL1HgN9InGvSB4tPbXm1H4Nleb08coIIOnFIw91CbD6iwXhKeJWZyNxgN7khQmeLhLqAA= x-ms-exchange-crosstenant-network-message-id: 5f3d40ca-d1c4-4e94-26ea-08d7526899af x-ms-exchange-crosstenant-originalarrivaltime: 16 Oct 2019 18:42:30.2195 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 1eLdLRI3ZlVWlrUhOo/Js5PB6t9cg6zTnpRg2fHdxYq3OBQj9Lco2Ss6IIwCnVIDUe8yDR/JZM13KdbY81hFJwKdghHOODCQkRDIVNrhiwo= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4241 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <3906AC5C7637EF4196F6B4D4707D0FD2@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22SbUhTURjHO/dlu5MGx6n5YBm10ErIpZgZmVQoKRWpXwJj5c0d01wqd1PS viyzt623paItctpm4ktKhmSjD00q0mWC5ArNypfMQAmEKKO0rndBkOfT7/+c//M/zzkcjlb9 ZEO43HwjEfJ5vVrmx2QaUuI2OXWN2s1lT4LjFjxtsriqKzt2UslO5xyVXHHPxqRSGSYUb8wR CG9MJNkk30AS/Nb8t+KPkuwCgSTxgr4knegJv7RNdOqIPreYCJolYzRL5mSaqRzPwx6m8Irf ybLhUdaEphVmpOAAx8DNr9flZuTHqbCbgo+dH2hJuBAMtDh8YhBBq6XfZ3uKoP7CECOJCgpe fn/vE2MI+qoH5GKyDMfCSP0rWuRAnACeixIH4J3Q4LpKmRH3p74LLnwJkCy7YdjaxIjM4DB4 MtTCiqzEibDQfsmX30CBZWF2MUeB0+DbaM1iA8Ir4FtvKyUyjYNhaMJOSbfD4HzUT0scBJ/H 51nx3CCsgZqRCKlVBw7zbZ9dDecb7XKJQ2HAbkGiHfB+GLgTJpUjYPD0O1biPJgeOyOTOBwe ePt9MavAWmVhxZEBj7HQ5Z1azFHh4zAzmCB5VkPz5VHmGoqx/TO07Y+Lxhuh3aWRysnwqd4h k3gtVFpG5bbFR/GHnhsTTB1im9HybbGRUVExkdFxkVu3dCDxTwqr9nahtrk93QhzSL1cmZ7S qFWxfLGh5EQ3Ao5WByrt5U6tSqnjS0qJUHBEKNITQzdayTHqYOV8a51WhY/xRpJHSCER/u5S nCLEhGqqot2dU6HLKt2Nt/y55qxNSdsLcx2Kw9dqlaWe5Ja34R15prT2N88mUtPvTz69WPnr R+l4U/akt3pD/WNvoNv4PCtjrXv4WVPvurJ4MldlM2s76k55Sw+88KRbHezcvr5D9vX2LKF8 Nikh5kftXde5wflfVnnR6367IDuYOHNWzRhy+KgIWjDwvwFzZ9wtjwMAAA== Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 16 Oct 2019 18:42:47 -0000 PiBGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUmljaGFyZCBC YXJuZXMgPHJsYkBpcHYuc3g+DQo+IElmIHRoaXMgY2hhcnRlciBpcyB0byBnbyBmb3J3YXJkLCBp dCBzaG91bGQgYmUgcmVmYWN0b3JlZCB0byBmb2N1cyBvbiBlbmdpbmVlcmluZyBxdWVzdGlvbnMs IGFuZCBhdm9pZCBwb2xpY3kgcXVlc3Rpb25zLg0KDQpbSkxdIFBlcmhhcHMgb25lIGlzc3VlIGlz IHdoYXQgd2UgZWFjaCBtZWFuIHdoZW4gdGhlIHdvcmQgJ3BvbGljeScgYXJpc2VzLiBDbGVhcmx5 IHdlJ3JlIHVubGlrZWx5IHRvIGdldCBjb25zZW5zdXMgb24gd2hhdCBpcyB0aGUgJ2NvcnJlY3Qn IHBvbGljeSBhY3Jvc3MgYSB2YXJpZXR5IG9mIGNvdW50cmllcyBhbmQgc29jaWV0aWVzLiBPbiB0 aGUgb3RoZXIgaGFuZCB3ZSBtYXkgd2VsbCBiZSBhYmxlIHRvIGFncmVlIG9uIGEgd2F5IHRvIGRl ZmluZS9kaWZmZXJlbnRpYXRlLCBkb2N1bWVudC9zaWduYWwsIGFuZCB0ZXN0IHN1Y2ggcG9saWNp ZXMuIEZvciBleGFtcGxlLCBOWERPTUFJTiByZWRpcmVjdGlvbiAod2hpY2ggSSBkbyBub3Qgc3Vw cG9ydCkgLSB0aGUgV0cgbWF5IG5vdCBhZ3JlZSBvbiB3aGV0aGVyIHRoaXMgaXMgZ29vZCBvciBi YWQuIEJ1dCB0aGUgV0cgbWF5IHdlbGwgYWdyZWUgb24gaG93IHRvIGRlZmluZSBpdCwgaG93IGFu IG9wZXJhdG9yIG1heSBzaWduYWwgdGhhdCBzdWNoIGEgcG9saWN5IGNvbmZpZyBpcyBpbiBwbGFj ZSwgaG93IHRoaXMgbWlnaHQgYmUgdGVzdGVkL3ZhbGlkYXRlZCwgZXRjLiBCYXNlZCBvbiB0aG9z ZSBwb2xpY2llcywgb3BlcmF0aW5nIHN5c3RlbXMsIGFwcHMgb3IgdXNlcnMgY2FuIHRoZW4gZGV0 ZXJtaW5lIGhvdyB0byBhY3Qgb24gdGhhdCBpbmZvcm1hdGlvbiwgZXRjLiAoT3IgbWF5YmUgSSBh bSBqdXN0IGJlaW5nIG9wdGltaXN0aWMuKQ0KDQoNCg== From nobody Wed Oct 16 11: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 68C77120116 for ; Wed, 16 Oct 2019 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CsqCoQtlbqe for ; Wed, 16 Oct 2019 11:47:51 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 7458E12010F for ; Wed, 16 Oct 2019 11:47:51 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id e66so3201218qkf.13 for ; Wed, 16 Oct 2019 11:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EZuG4/baNoh9oPL11s7vEyRGzv4c45PhqbJq2KDRy3k=; b=di5vhbuXKlewFRsBxuSv0tQibfYZiv5AxPWUZ8a7DBH6NABZh/mHt2lL6mGlKvucOV V2dt3AjnBxP4jzuYJP9eOEdAfB6de/I/BajoAmli6BqfUpNt9gRahgK/PJm6iuo0/XBS /eTlDtpFw+Kh8SU85qHy9H89NoPNH2ro9V8dz75ekhjIk/VtIHg/tD+LM8dsHF/xrY7I CCzAH2z3/gutvDYbiH3OFAGZXPU5bFalbULnojIZXb1RhEE0J6BcNLrxxd6UzZCDcw7v b786hcGccp+//m0y7FULcdVQGpy4FUpR83I9vJDVF31Ie0PURzCXjmJeUsalZwh0SFaJ sG4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EZuG4/baNoh9oPL11s7vEyRGzv4c45PhqbJq2KDRy3k=; b=S0iuXvwxKDCmkayLEz51oGP7/eimWq8usF0s+7xeR1y9U1giMAIaHbrG+KJ0+LFPc5 ZS3gpgtP1ruBRpAaNWsuTInKsd7iHbqg1G/NFC/M5aCFlwlFZ5DxBVUt6WvcEG9Nv44G mIoA4omY1ObpzAo2S9H7OUj271WbnLKlbUHdJXI+zSnYLkNaJithwQwnCVljzkSQr0P8 wSED1NdA6suiFwYW83GlK7SvF3iB3NdwtDZ1Q/SGjoKlHdGyrZ1EsAbKi0xa7GYDtMT7 6tq+kmr9MBlkKhlq9NVIorKbJUWiho+6JNZdM4oJD4VXxeTqgddJaQRCQFNrNu3jlPNc FFWQ== X-Gm-Message-State: APjAAAWEbha+n2bKD8GiEJa2PsPFd0KG4/v/HBI12+lsMB+ZdI/RyQYy v3ud/Npl2xIHgDheWiLderfJ8w== X-Google-Smtp-Source: APXvYqzWXV+nBBbqNYo0Y6vqFc0flVJu0oIp5dcnzUVxa6RSmMqoZB67QI35tIXT6B+SZD/S3P2UnA== X-Received: by 2002:a05:620a:215b:: with SMTP id m27mr5118361qkm.328.1571251670278; Wed, 16 Oct 2019 11:47:50 -0700 (PDT) Received: from [10.0.100.13] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b4sm12099409qkd.121.2019.10.16.11.47.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Oct 2019 11:47:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16G77) In-Reply-To: <7330B585-68C9-4706-952F-E83A5604FC86@cable.comcast.com> Date: Wed, 16 Oct 2019 14:47:49 -0400 Cc: Richard Barnes , "add@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7330B585-68C9-4706-952F-E83A5604FC86@cable.comcast.com> To: "Livingood, Jason" Archived-At: Subject: Re: [Add] Proposed charter and BoF request for IETF 106 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, 16 Oct 2019 18:47:53 -0000 On Oct 16, 2019, at 2:42 PM, Livingood, Jason w= rote: >=20 > But the WG may well agree on how to define it, how an operator may signal t= hat such a policy config is in place, how this might be tested/validated, et= c. Based on those policies, operating systems, apps or users can then determ= ine how to act on that information, etc. (Or maybe I am just being optimisti= c.) This sounds analogous to =E2=80=9Cdo not track.=E2=80=9D Is there something= about this that would lead to a different outcome? If I know I am not acti= ng as the user would prefer, would I not just say nothing?= From nobody Wed Oct 16 12:58: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 D973712080C for ; Wed, 16 Oct 2019 12:58:47 -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_HELO_NONE=0.001, 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 J4Pe6uJrGtoL for ; Wed, 16 Oct 2019 12:58:45 -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 B9339120122 for ; Wed, 16 Oct 2019 12:58:45 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q1so65993ion.1 for ; Wed, 16 Oct 2019 12:58: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=/qpltz2QHK4IKiTBLXtxcxzZRAla7jsIqhG/SnuArgw=; b=bRSjLOqCEzRgJVhudfxaFPvNgrJR74ijaYRX9yeHvS8R4b5O+9/edHG8i8C0fCjPiB 8OfmZF7X6FozAlqF9AdG9In7qwO/CHq7H1EH7BXCga0EVUngzqsdqnbxvkGg/pouxNPM VGPqDIfy1jSF5sRO4SVz4S3cCNViG6xU3p436uJaXhhJIHtZN+KmDkt5EPQWH82WNlbM NB5+S4TBGLtuzEs6+HC48DeV78a6xI3g1eye0ZQCxomqgTT32ylVs0otrR4jqMW0B6+5 1yLKLjZ1F1ftGhtAhfA2J5Yb92VJSeS4faM5F5ud9TVLrtXfF0/CCU9XrIP1SE7I2Cz/ TDRg== 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=/qpltz2QHK4IKiTBLXtxcxzZRAla7jsIqhG/SnuArgw=; b=YCE/ZKtH1pWfXmPWY2UiIef8GsSZjbigVViy1wpx68vurAzR1NZLYqDlNSTkQ4zcwm Isg9EirIvJlnwAd7I7yDySCKLbp29yixnfnvzfbIwuN3bhowe1zfFWWy/kBI45tUaYAd 6qN2TrYVRmFcM6XIsv9cx7cYi7saguuUVG4ApzA4Bk/BJ1l6n2eqgJ8+5HXUdzRR+5VH v9XmIlx6P8B+CpykwUEdmLB3IpXuyZ/4B1Qh/yH2gFrwzVmU7Ds+EQdgC1SQZoyBi0vs CvPkyE8Cawco/9phTlqiK59txk1xKmjeHsh/oGytH2BIQsM/m9RcTZTCpm85vDM0gRPR wg1A== X-Gm-Message-State: APjAAAUQA26wAWXY6nxZS0EqTdU9vrpLY40d9s34yzmUtqVXgJLhowyP BB+lusjJZT/prWHj6320N8/A3lijJmYjBkBkQW9e31VzDN4d4g== X-Google-Smtp-Source: APXvYqyT1TTwboKBmZD+ZLZcAolHctjCfV9DYmlddfmR73wjzxPJBgpGlN15pDMtUNdyvePFRUw+Qz0Pa/SpmqZvVlM= X-Received: by 2002:a6b:f90f:: with SMTP id j15mr28667263iog.257.1571255924428; Wed, 16 Oct 2019 12:58:44 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Wed, 16 Oct 2019 12:58:33 -0700 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000003a188905950c879e" Archived-At: Subject: [Add] charter feedback: the network operator 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, 16 Oct 2019 19:58:48 -0000 --0000000000003a188905950c879e Content-Type: text/plain; charset="UTF-8" "various application providers have been exploring having the application configure its own DNS services rather than using DNS services configured by the network operator. (The working group considers a network operator to include Internet service providers, enterprises, and any businesses that provide network access.)" I have some specific feedback on this section of the charter. First, I like its attempt to define "network operator". It makes a well-intentioned attempt to rule out tedious "My home is my castle" arguments [0]. However, this space is subtle. One problem is that many "network operators" under the BoF's definition deploy devices in homes that make choices, can get exploited, etc. Some text that explains the untrusted path that unencrypted DNS takes might help. The text about "various application providers have been exploring having the application configure its own DNS services" seems wrong. They already do it in many ways, from VPNs to DoH/DoT and centralized DNS services. thanks, Rob [0] https://github.com/http2/http2-spec/wiki/Proxy-User-Stories#my-home-is-my-castle --0000000000003a188905950c879e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"various application providers have been exploring ha= ving the application
configure its own DNS services rather than using DN= S services configured
by the network operator. (The working group consid= ers a network operator
to include Internet service providers, enterprise= s, and any businesses
that provide network access.)"

=
I have some specific feedback on this section=C2=A0of the charter. Fir= st, I like its attempt to define "network operator". It makes a w= ell-intentioned attempt to rule out tedious "My home is my castle"= ; arguments [0].

However, this space is subtle. On= e problem is that many "network operators" under the BoF's de= finition deploy devices in homes that make choices, can get exploited, etc.= Some text that explains the untrusted path that unencrypted DNS takes migh= t help.

The text about "various application p= roviders have been exploring having the application
configure its own = DNS services" seems wrong. They already do it in many ways, from VPNs = to DoH/DoT and centralized DNS services.

thanks,
Rob

--0000000000003a188905950c879e-- From nobody Wed Oct 16 14:03: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 F2BE6120123 for ; Wed, 16 Oct 2019 14:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.248 X-Spam-Level: X-Spam-Status: No, score=-9.248 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.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 cUdr6xtBGkwN for ; Wed, 16 Oct 2019 14:03:01 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 0F8C212007C for ; Wed, 16 Oct 2019 14:03:01 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id v17so260564wml.4 for ; Wed, 16 Oct 2019 14:03:00 -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=aUbl2Sel//Eb/R4p+4mv5O3zSvUCdFzwI7TRA++V/F8=; b=IeWM/T9hN5GCmCbd03lW2CfYMnVVVLfiC42CwCLWllQbyQlBMkAWgaRbDfnDzRpDUR D/PRg6n7BhmkyGicb7ckY6nUBgndL1IjHUbXaaYh4kwXuaNRChi7/uYl1ICJ8Ayb90ux 830QbhLYOkPNf3dxmJ8UuduhTFHS8c2ibHMNk= 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=aUbl2Sel//Eb/R4p+4mv5O3zSvUCdFzwI7TRA++V/F8=; b=ta+ib5ntrW2vETdtTgfnfwyXZUeRdukYv9DD8Q1c8d8kPdyLO4Ru46q5CNGy+QHL96 zf356M00B1QwNjRjXFMuP13ltlIacqg7T+qUBJLP0tljb9Ow1+cZxrcToQ//compr2ah nRQ/pguOPKlteB9pzWk9u3h3Bhcgxmkg3ANtTO2iDpyPQNpR3xzx017tMPXw1Nio58oy AEVLahGF5n+zwvMX0BF+TJh7o/nBYkTuhDI09ewnR0GijbIvHXigVMTTfA+vrlPOg0T+ baNnAvHJisfyIIk8OkdYLCcItUpxc05Z5ZcybuRj5BxEGCYwrMK9ltoh43FBn7YDiBjl /wZA== X-Gm-Message-State: APjAAAVPmR/JQoI7e5+eFuDRDcNse3aIctWmuYxacBUbBc9IkjL7evUG 6q5RbKCzhrkAoyTSxhBGhQst+3jC7sp7DiJifckqcg== X-Google-Smtp-Source: APXvYqzJ5/qH8O0HP4O+zr5KmOIck8U2uyUFLJP4XGgWASNIt5bPYBegLLypYiG9y/rAWUXizZF0Tx4W0J5EexSkYfU= X-Received: by 2002:a1c:1bc5:: with SMTP id b188mr5268229wmb.88.1571259779060; Wed, 16 Oct 2019 14:02:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: ek@loon.com From: Erik Kline Date: Wed, 16 Oct 2019 14:02:46 -0700 Message-ID: To: Rob Sayre Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000fb8ef405950d6c08" Archived-At: Subject: Re: [Add] charter feedback: the network operator 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, 16 Oct 2019 21:03:03 -0000 --000000000000fb8ef405950d6c08 Content-Type: text/plain; charset="UTF-8" How about just saying "provisioned by the network (e.g. DHCP, RDNSS, ...)"? On Wed, 16 Oct 2019 at 12:59, Rob Sayre wrote: > "various application providers have been exploring having the application > configure its own DNS services rather than using DNS services configured > by the network operator. (The working group considers a network operator > to include Internet service providers, enterprises, and any businesses > that provide network access.)" > > I have some specific feedback on this section of the charter. First, I > like its attempt to define "network operator". It makes a well-intentioned > attempt to rule out tedious "My home is my castle" arguments [0]. > > However, this space is subtle. One problem is that many "network > operators" under the BoF's definition deploy devices in homes that make > choices, can get exploited, etc. Some text that explains the untrusted path > that unencrypted DNS takes might help. > > The text about "various application providers have been exploring having > the application > configure its own DNS services" seems wrong. They already do it in many > ways, from VPNs to DoH/DoT and centralized DNS services. > > thanks, > Rob > > [0] > https://github.com/http2/http2-spec/wiki/Proxy-User-Stories#my-home-is-my-castle > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000fb8ef405950d6c08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How about just saying "provisioned by the network (e.= g. DHCP, RDNSS, ...)"?

On Wed, 16 Oct 2019 at 12:59, Rob Sayre <sayrer@gmail.com> wrote:
"vari= ous application providers have been exploring having the application
con= figure its own DNS services rather than using DNS services configured
by= the network operator. (The working group considers a network operator
t= o include Internet service providers, enterprises, and any businesses
th= at provide network access.)"

I have some specific f= eedback on this section=C2=A0of the charter. First, I like its attempt to d= efine "network operator". It makes a well-intentioned attempt to = rule out tedious "My home is my castle" arguments [0].
=
However, this space is subtle. One problem is that many &quo= t;network operators" under the BoF's definition deploy devices in = homes that make choices, can get exploited, etc. Some text that explains th= e untrusted path that unencrypted DNS takes might help.

The text about "various application providers have been explorin= g having the application
configure its own DNS services" seems wr= ong. They already do it in many ways, from VPNs to DoH/DoT and centralized = DNS services.

thanks,
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000fb8ef405950d6c08-- From nobody Wed Oct 16 15:53: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 E7625120086 for ; Wed, 16 Oct 2019 15:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 PruP8cDsUetb for ; Wed, 16 Oct 2019 15:53:43 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 17EC5120052 for ; Wed, 16 Oct 2019 15:53:43 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id d1so384735ljl.13 for ; Wed, 16 Oct 2019 15:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=mep32PmA6CAuiuSjpyvaZWdoUO3Gu/72OBBuv7FKYXs=; b=br1QqJak0LYt6dsLxxE77i+DgCtqjc7I5gDBGALczXLzYcITByMygrFmb/31Hi+76q FWruA3u6VbzkDTA2MnEoB0c55IejbExmJf8owp+2i+KEXGpkIl1SWxY+Kfalqf/Rjg03 b84w5wl3Zq2fo+7atYivy2I6E7cjTRvVSN39s= 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:references:in-reply-to:date :message-id:subject:to:cc; bh=mep32PmA6CAuiuSjpyvaZWdoUO3Gu/72OBBuv7FKYXs=; b=Utx2n83nhNqcMriOJ7nfeigKgEBtY8R7nLyDG74u0h49CxvcIXPE5B+gfmwfvi3+Yb VYeQdMntwALVczyph9QUinGyXHcrJ6/ZxO+3p94DvDpQ8lNTYXkcnBB5iRM56lC4JO/7 nB2JQHnFicgl/3Hx5begfUl4KRj9af3BFndm0aMWGnwfaOv/XRU/E2dJhRy8QBEH602p bN5Uaxoyg1bHI2EED3oLLrHTepFfJdr10XLpkEcQqhbsMX7MLB88/mEnlnZkPLVhD2wv H4ofpKOHRpRCYcZy3Tkyu2AlJhDH54tzDKBFJOov25puMvw+548AUHVAcSierZP6NZe2 yjeA== X-Gm-Message-State: APjAAAVl07cpmuOb1B/bccihNSG2YuXEuRrFKXBCRCFIKnlRTbQ0fSP+ T8NgG+wm75YFJT7mp5ebu7rdP7DxjN5HKyrudnjj7w== X-Google-Smtp-Source: APXvYqzh6inGYWcrsF0oFuQMKnpp7FY/FbbHuwdhMizC3c9rszjVdvTfNCfYMNVQQPJEaycupJALH21zEMkPxx6MmbY= X-Received: by 2002:a2e:9a99:: with SMTP id p25mr304097lji.171.1571266420903; Wed, 16 Oct 2019 15:53:40 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Wed, 16 Oct 2019 15:53:39 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Wed, 16 Oct 2019 15:53:39 -0700 Message-ID: To: Rob Sayre Cc: ADD Mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] charter feedback: the network operator 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, 16 Oct 2019 22:53:45 -0000 On Oct 16, 2019, at 21:58, Rob Sayre wrote: > The text about "various application providers have been exploring having the application > configure its own DNS services" seems wrong. They already do it in many ways, from VPNs to DoH/DoT and centralized DNS services. It seems reasonable to me that to explore a place you have to spend time there. I don't think the text is at odds with your observation. Joe From nobody Fri Oct 25 14:15:56 2019 Return-Path: X-Original-To: add@ietf.org Delivered-To: add@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A401209A5; Fri, 25 Oct 2019 14:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: add@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793073.2724.9554146873248706955.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:10 -0700 Archived-At: Subject: [Add] abcd - Requested session has been scheduled for IETF 106 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:12:20 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. abcd Session 1 (2:00 requested) Tuesday, 19 November 2019, Afternoon Session I 1330-1500 Room Name: Padang size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/abcd.ics Request Information: --------------------------------------------------------- Working Group Name: Application Behavior Considering DNS Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Technology Overlap: dprive dnsop artarea People who must be present: Barry Leiba Resources Requested: Special Requests: ---------------------------------------------------------