From nobody Wed Jan 1 12:45:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56338120096 for ; Wed, 1 Jan 2020 12:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 31X6XBZkE8Z2 for ; Wed, 1 Jan 2020 12:45:43 -0800 (PST) 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 908A212001A for ; Wed, 1 Jan 2020 12:45:41 -0800 (PST) Received: from xse74.mail2web.com ([66.113.196.74] helo=xse.mail2web.com) by mx35.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1imks2-0004or-Tm for add@ietf.org; Wed, 01 Jan 2020 21:45:37 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 47p38W3371z1L3c for ; Wed, 1 Jan 2020 12:45:31 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1imkrz-0008BL-AJ for add@ietf.org; Wed, 01 Jan 2020 12:45:31 -0800 Received: (qmail 32444 invoked from network); 1 Jan 2020 20:45:30 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Jan 2020 20:45:30 -0000 To: Rob Sayre , John Levine Cc: ADD Mailing list References: <20191231020124.5B7DB11D768C@ary.qy> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> Date: Wed, 1 Jan 2020 10:45:29 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------857113CEF89611C4BBC0E317" Content-Language: en-US X-Originating-IP: 66.113.196.74 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.74/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.74/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0c2Pj46HODYmpAMVAv0J1pOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4Ypr1nEu9dlN4gFZWWWti16gyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+celWigidmUBfpu1oPmNJeGmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnJKElQ6hFn6n 7azFkqLcyCJXuaMUA+OKvwl5hKOU+1KEPu87B3hyiYv83MRoXW2ijLlOLW1L4Zjbt9CMjMreolNP wppzYiooDLb5c/hDYtVwOqm8/r0+qTPcKikROuC+AF1677oPXF7r5zsW33ZNliqIq+4OHAbcrjdy bIN12EZeWDvBhuNO4tpnc980Bg7nrTEnTpyPkmu5IbKgpbRwbYyw0/tiwazDGSKXoad81i4BXPWl FdaGOH191uXjgjQN/bk/tOvsMDZmQNfeGxdXg4FDfv4TYbVwkrVxPm8rlSfu83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 01 Jan 2020 20:45:45 -0000 This is a multi-part message in MIME format. --------------857113CEF89611C4BBC0E317 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/30/2019 4:08 PM, Rob Sayre wrote: > > > On Mon, Dec 30, 2019 at 6:01 PM John Levine > wrote: > > In article > > you write= : > >Here is a lobbying letter from an industry association: > >https://www.ncta.com/sites/default/files/2019-09/Final%20DOH%20LET= TER%209-19-19.pdf > > > >It is from September 19th, 2019. It mentions advertising > explicitly. There > >are numerous press articles about this letter, so I won't delve > further > >into its contents. > > The letter you linked to is two pages of FUD accusing Google of > planning to do all sorts of terrible things without a shred of > evidence.=C2=A0 It is flatly contradicted by Google's own statement= s about > their DoH deployment plans. > > > I can't say I disagree with your assessment. > > But, the letter does mention that encrypted DNS might harm competition > in the advertising space. The actual text is: > > "This could inhibit competitors and possibly foreclose competition in > advertising and other industries." > > How could encrypted DNS harm competition in advertising if unencrypted > DNS weren't being used for advertising? The NCTA letter is obviously framed by telco lawyers attempting to sue Google for some alledged potential antitrust violation. The argument appears to be that by blocking the leakage of private information to network providers, Google is allegedly attempting to prevent these network providers to capture the personal data required to "build better advertisements" and thus compete with Google. Or, put it another way, leakage of personal data is a goldmine that is making Google and Facebook rich, and these telco lawyers are furious at anything that would prevent them from also digging the mine. That includes being furious not just at Google, but also at any other attempt to plug the leaks, including the relatively feeble attempts of the IETF. I have zero sympathy for the argument of the telco's lawyers. I believe all this trafficking in personal data should stop. But I also believe that deployments should be carefully engineered to actually reduce leakage, not merely move the leaks around. -- Christian Huitema --------------857113CEF89611C4BBC0E317 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/30/2019 4:08 PM, Rob Sayre wrote:


On Mon, Dec 30, 2019 at 6:01 PM John Levine <johnl@taugh.com> wrote:
In article <CAChr6Sxm2GuHFTqOjtq=osZKGCBOVi+YSk7mY9F5-Lph_xvDjA@mail.gmail..com> you write:
>Here is a lobbying letter from an industry association:
>https://www.ncta.com/sites/default/files/2019-09/Final%20DOH%20LETTER%209-19-19.pdf
>
>It is from September 19th, 2019. It mentions advertising explicitly. There
>are numerous press articles about this letter, so I won't delve further
>into its contents.

The letter you linked to is two pages of FUD accusing Google of
planning to do all sorts of terrible things without a shred of
evidence.  It is flatly contradicted by Google's own statements about
their DoH deployment plans.

I can't say I disagree with your assessment.

But, the letter does mention that encrypted DNS might harm competition in the advertising space. The actual text is:

"This could inhibit competitors and possibly foreclose competition in advertising and other industries."

How could encrypted DNS harm competition in advertising if unencrypted DNS weren't being used for advertising?


The NCTA letter is obviously framed by telco lawyers attempting to sue Google for some alledged potential antitrust violation. The argument appears to be that by blocking the leakage of private information to network providers, Google is allegedly attempting to prevent these network providers to capture the personal data required to "build better advertisements" and thus compete with Google.

Or, put it another way, leakage of personal data is a goldmine that is making Google and Facebook rich, and these telco lawyers are furious at anything that would prevent them from also digging the mine. That includes being furious not just at Google, but also at any other attempt to plug the leaks, including the relatively feeble attempts of the IETF.

I have zero sympathy for the argument of the telco's lawyers. I believe all this trafficking in personal data should stop. But I also believe that deployments should be carefully engineered to actually reduce leakage, not merely move the leaks around.

-- Christian Huitema

--------------857113CEF89611C4BBC0E317-- From nobody Wed Jan 1 14:17:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43152120020 for ; Wed, 1 Jan 2020 14:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 hgxZj08GdGae for ; Wed, 1 Jan 2020 14:17:20 -0800 (PST) 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 3A74312000F for ; Wed, 1 Jan 2020 14:17:20 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id b10so36769070iof.11 for ; Wed, 01 Jan 2020 14:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m241Lmu/94hxrwAXfmDNQuxAorVcoA/GlNbBss12rTc=; b=TFpk94rYsrdi1cOm9t/BfixHO81FyYdS/3VUCcyzaVyIYVKc9bRTxrBRbJQI6xS9dv DQCzMjOsQujgStVsntl9B0q9XhvxmRU7EdZpni5KwIXDbyLb1ZLHgCXLxMjr93IVvE0V 3EvvXO+MD4p7wFWe3Sm1EBwM4ff5JCdXcLoiuLo8sRzXJ4uALB3ssQ4N5jmC8P9duXu1 Ky3EyOqwa1l/r4tgwXVPKFuGjmclwEl7LlVQ7SSdAJ6FK/EWy1VFqLWDRpx34sXbUHgd l+UnfUxx5u9SAF/0xL5ob6mhAzqwwXNZuMLTAKu1OEKOcgWqz76E+Z/V6kEbX3R4Nq6W kT+Q== 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=m241Lmu/94hxrwAXfmDNQuxAorVcoA/GlNbBss12rTc=; b=BXYlIa7fLNIj7rpZbMkfmSNQL+NRcFEXfnvw4rddAjXIbsfgvESwG7Btsx61uWvuXI 3eDtOciQGF0iqEVTSzGUsLo2CZkIgmsghcGcLuSsRdHQyJ6ebPd4AYfUfQeLrSpdfazW OnKZS4430lnI1eZfz0CmsncHhuMoIHLjWBK+uirEMBtVjb5N/0dEsf/Va7TbiR+K2613 GhBkACKPshBjtTXiykh0eBuza3jKZwhhUrYYg/yUxiNXMoXbotDjv8mwSJP7umMi8ifM IWrhOwsbqXTEvss2/dpbH70/+mqpXRlIZUysDDK+lgh3xCZ34U0G6+8hBig4EAqJirwN KkHQ== X-Gm-Message-State: APjAAAUlOwbi9QDYdFYNocrHScJY+LLkChjCDkZam4hTAg3gtjDUh+hy K63Ls7ZQfmycl+zEq8Oe0r6pz2Q7TzJBZWuJI8tL7kgt X-Google-Smtp-Source: APXvYqy9afrwZjNPCzW47ODlK7XZr+QyjoXHw70RtzqGFnUKJ/awXjG6UYOFV/clGvR/P8l4pmJzEIuDIFEqk6M1Dr0= X-Received: by 2002:a6b:fc0c:: with SMTP id r12mr49836537ioh.189.1577917039387; Wed, 01 Jan 2020 14:17:19 -0800 (PST) MIME-Version: 1.0 References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> In-Reply-To: <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> From: Rob Sayre Date: Wed, 1 Jan 2020 14:17:06 -0800 Message-ID: To: Christian Huitema Cc: John Levine , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009e293e059b1b7055" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 01 Jan 2020 22:17:23 -0000 --0000000000009e293e059b1b7055 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 1, 2020 at 12:45 PM Christian Huitema wrote: > > On 12/30/2019 4:08 PM, Rob Sayre wrote: > > > > On Mon, Dec 30, 2019 at 6:01 PM John Levine wrote: > >> In article > osZKGCBOVi+YSk7mY9F5-Lph_xvDjA@mail.gmail..com >> > you write: >> >Here is a lobbying letter from an industry association: >> > >> https://www.ncta.com/sites/default/files/2019-09/Final%20DOH%20LETTER%209-19-19.pdf >> > >> >It is from September 19th, 2019. It mentions advertising explicitly. >> There >> >are numerous press articles about this letter, so I won't delve further >> >into its contents. >> >> The letter you linked to is two pages of FUD accusing Google of >> planning to do all sorts of terrible things without a shred of >> evidence. It is flatly contradicted by Google's own statements about >> their DoH deployment plans. >> > > I can't say I disagree with your assessment. > > But, the letter does mention that encrypted DNS might harm competition in > the advertising space. The actual text is: > > "This could inhibit competitors and possibly foreclose competition in > advertising and other industries." > > How could encrypted DNS harm competition in advertising if unencrypted DNS > weren't being used for advertising? > > > The NCTA letter is obviously framed by telco lawyers attempting to sue > Google for some alledged potential antitrust violation. The argument > appears to be that by blocking the leakage of private information to > network providers, Google is allegedly attempting to prevent these network > providers to capture the personal data required to "build better > advertisements" and thus compete with Google. > > Or, put it another way, leakage of personal data is a goldmine that is > making Google and Facebook rich, and these telco lawyers are furious at > anything that would prevent them from also digging the mine. That includes > being furious not just at Google, but also at any other attempt to plug the > leaks, including the relatively feeble attempts of the IETF. > > I have zero sympathy for the argument of the telco's lawyers. I believe > all this trafficking in personal data should stop. But I also believe that > deployments should be carefully engineered to actually reduce leakage, not > merely move the leaks around. > I don't disagree with that, I was only responding to the claim that ideas about ISP use of DNS data are misinformed (there are many ISPs, and they have many different policies). Certainly the responses to that telco letter indicate the topic is actively debated: https://www.vice.com/en_us/article/zmj5p9/mozilla-firefox-asks-congress-to-investigate-internet-service-providers-data-selling-collection Here is a web page about an experiment to detect query data sharing, including in Europe: https://blog.benjojo.co.uk/post/ISPs-sharing-DNS-query-data thanks, Rob --0000000000009e293e059b1b7055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Wed, Jan 1, 2020 at 12:45 PM Christian Huitema <huitema@huitema.net> wrot= e:
=20 =20 =20


On 12/30/2019 4:08 PM, Rob Sayre wrote:
=20


On Mon, Dec 30, 2019 at 6:0= 1 PM John Levine <johnl@taugh.com> wrote:
In article <CAChr6Sxm2GuHFTqOjtq=3DosZKGCBOVi+YSk7mY9F5-Lph_x= vDjA@mail.gmail..com> you write:
>Here is a lobbying letter from an industry association:
>h= ttps://www.ncta.com/sites/default/files/2019-09/Final%20DOH%20LETTER%209-19= -19.pdf
>
>It is from September 19th, 2019. It mentions advertising explicitly. There
>are numerous press articles about this letter, so I won't delve further
>into its contents.

The letter you linked to is two pages of FUD accusing Google of
planning to do all sorts of terrible things without a shred of
evidence.=C2=A0 It is flatly contradicted by Google's own statements about
their DoH deployment plans.

I can't say I disagree with your assessment.

But, the letter does mention that encrypted DNS might harm competition in the advertising space. The actual text is:

"This could inhibit competitors and possibly foreclose competition in advertising and other industries."

How could encrypted DNS harm competition in advertising if unencrypted DNS weren't being used for advertising?


The NCTA letter is obviously framed by telco lawyers attempting to sue Google for some alledged potential antitrust violation. The argument appears to be that by blocking the leakage of private information to network providers, Google is allegedly attempting to prevent these network providers to capture the personal data required to "build better advertisements" and thus compete = with Google.

Or, put it another way, leakage of personal data is a goldmine that is making Google and Facebook rich, and these telco lawyers are furious at anything that would prevent them from also digging the mine. That includes being furious not just at Google, but also at any other attempt to plug the leaks, including the relatively feeble attempts of the IETF.

I have zero sympathy for the argument of the telco's lawyers. I believe all this trafficking in personal data should stop. But I also believe that deployments should be carefully engineered to actually reduce leakage, not merely move the leaks around.

<= /blockquote>

I don't disagree with that, I was only = responding to the claim that ideas about ISP use of DNS data are misinforme= d (there are many ISPs, and they have many different policies).
<= br>
Certainly the responses to that telco letter indicate the top= ic is actively debated:

Here is a web page a= bout an experiment to detect query data sharing, including in Europe:
=
thanks,
Rob



=C2=A0
--0000000000009e293e059b1b7055-- From nobody Wed Jan 1 17:24:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405341200DF for ; Wed, 1 Jan 2020 17:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJFSr53_7Pdj for ; Wed, 1 Jan 2020 17:24:15 -0800 (PST) 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 3302212001E for ; Wed, 1 Jan 2020 17:24:15 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id j26so39274028ljc.12 for ; Wed, 01 Jan 2020 17:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m56CMNpCmg0JP5htc3y7nXt0c8qFY5qqbVVzRFku7oU=; b=FGc5CYPufasPdm54VlwTo+ZhHHsFZDmyeH/XcolskHM8EeKnyrp2ZaQu0VRedAEWBq M41/B5hFBDqrWBBtAf8Z27EfnEmRigxtEkiuivX+XMRnpapDFhEeOiEhSE4mk/oLy45K 4uQW4KNT+XjxyYPgUH0PBRnN2wrkzx7wMh56Nx0LMgl/Y4Sl7dS+yncGliRsMeXD95NB NR4ns3vAz+F3eTrmykiGVvOq8wmZt2z8easGRWPNp+njHdM5KAA4cc7m6+QsliCzSMoO fRkX2lcxFgLY/iwneEN56RJnKbwLKFJi2lXKZpHit5g3fr1ACldR6eJwBl9L53qZ127m McaQ== 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=m56CMNpCmg0JP5htc3y7nXt0c8qFY5qqbVVzRFku7oU=; b=pDQ8sM+fIdzzYGZCiR9VJanvC/hFwPNTWkwv2Y36OC/Ko0dpnEliprPeOd7xiX0Un5 BgU/dwmwhA7tALMZb+0OakgWoFsEY9rejgLX/gtuW+GBnanMUwskyosQOJdGK7t8XIXA ozGj9raU8ukcQ8wWOoZePDWy4WR2+JVpR/IuSnFb2XkabwZXTNsfe3uC2p1IFmz6OhrY 8vewsp6NNXOBwdG4UMNuZ3+oHJhDhK6zk+2kZH84ZGV7OAyOQ/yEF7j/cqrJISy6mN8W eyILq7cPe5LQRf/3SaFmiOMjGjYodqeeoIVgdU0PZufMqElIXmdRgGLzrs12STqrlrLT e8vg== X-Gm-Message-State: APjAAAXVJT7GOlvdS/BHeSLzXKJOYzB2BG8RW7mGyRTnQXgJerlPfLEf VPAsxqW4bPQp1NJ7eNIfpez407QNazOiqzDFbkrZ/d2zw9U= X-Google-Smtp-Source: APXvYqxvIcImw3JGcWwA1r1la2AvM782Nhlw9eBGqZ7y2RlCawEyWawf8Lh5Jeck9APq8t7h+oxb943OILup2drXvV0= X-Received: by 2002:a2e:95c4:: with SMTP id y4mr46753337ljh.38.1577928253488; Wed, 01 Jan 2020 17:24:13 -0800 (PST) MIME-Version: 1.0 References: <24278.1577216347@localhost> <56E5E3F3-23DD-494F-8C70-E8A5CAC8D0DA@huitema.net> In-Reply-To: <56E5E3F3-23DD-494F-8C70-E8A5CAC8D0DA@huitema.net> From: Eric Rescorla Date: Wed, 1 Jan 2020 17:23:36 -0800 Message-ID: To: Christian Huitema Cc: Michael Richardson , ADD Mailing list , Vittorio Bertola Content-Type: multipart/alternative; boundary="00000000000007cf57059b1e0dcb" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 01:24:17 -0000 --00000000000007cf57059b1e0dcb Content-Type: text/plain; charset="UTF-8" On Tue, Dec 24, 2019 at 12:10 PM Christian Huitema wrote: > > > On Dec 24, 2019, at 9:39 AM, Michael Richardson > wrote: > > > > > > Vittorio Bertola > wrote: > >> I think that one actual problem that many here would like to solve is: > >> for decades we have been discovering and using the local > >> network-provided resolver as a default, we would like to continue doing > >> that but with an encrypted local resolver, how do we do that? > > > > While I'm with you, I'm not sure that this is what others want. > > You are assuming that people obviously want to continue doing what they > are doing but only with an encrypted access to a local server. Rather than > assuming that, it might be better to unpack the tradeoff behind that > particular solution, and explain in which circumstances they make sense. > I would also like to push on this, but for different reasons. As usual, it's important to start with the threat model. If we start from the RFC 3552 threat model in which the attacker has complete control of the network, then learning that the local network has an encrypted resolver is not that useful as a mechanism to switch you from unencrypted to encrypted mode, because the attacker will just downgrade you or point you at their own resolver (this is just the usual point about encryption without authentication not being that useful). It seems like there are a few situations in which this kind of discovery is still useful: - You have a limited threat model in which you trust the local network but not the Internet - You have some sort of trust relationship with the discovery mechanism, e.g., the record is signed by a key you know (this is arguably a special case of the previous point) - You have multiple resolvers you trust via some other mechanism and the local network steers you to one. However, aside from these and others like them, an unauthenticated discovery function seems not that useful -Ekr > Personally I believe there is a difference between retrieving an A or > AAAA record and retrieving an ESNI record. Resolving the first one locally > may well be convenient. Resolving the ESNI locally leads to a very clear > privacy exposure. > > -- Christian Huitema > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000007cf57059b1e0dcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 24, 2019 at 12:10 PM Chri= stian Huitema <huitema@huitema.ne= t> wrote:

> On Dec 24, 2019, at 9:39 AM, Michael Richardson <mcr+ietf@sandelman.ca> wr= ote:
>
>
> Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org<= /a>> wrote:
>> I think that one actual problem that many here would like to solve= is:
>> for decades we have been discovering and using the local
>> network-provided resolver as a default, we would like to continue = doing
>> that but with an encrypted local resolver, how do we do that?
>
> While I'm with you, I'm not sure that this is what others want= .

You are assuming that people obviously want to continue doing what they are= doing but only with an encrypted access to a local server. Rather than ass= uming that, it might be better to unpack the tradeoff behind that particula= r solution, and explain in which circumstances they make sense.

I would also like to push on this, but for differe= nt reasons. As usual, it's important to start with the threat model.

If we start from the RFC 3552 threat model in which = the attacker has complete control of the network, then learning that the lo= cal network has an encrypted resolver is not that useful as a mechanism to = switch you from unencrypted to encrypted mode, because the attacker will ju= st downgrade you or point you at their own resolver (this is just the usual= point about encryption without authentication not being that useful).
=

It seems like there are a few situations in which= this kind of discovery is still useful:

- You hav= e a limited threat model in which you trust the local network but not the I= nternet
- You have some sort of trust relationship with the disco= very mechanism, e.g., the record is signed by a key you know (this is argua= bly a special case of the previous point)
- You have multiple res= olvers you trust via some other mechanism and the local network steers you = to one.

However, aside from these and others like = them, an unauthenticated discovery function seems not that useful
=
-Ekr




=


Personally I believe there is a difference between retrieving=C2=A0 an A or= AAAA record and retrieving an ESNI record. Resolving the first one locally= may well be convenient. Resolving the ESNI locally leads to a very clear p= rivacy exposure.

-- Christian Huitema


--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000007cf57059b1e0dcb-- From nobody Wed Jan 1 19:46:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EBE12003E for ; Wed, 1 Jan 2020 19:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 k1LixqjtVARQ for ; Wed, 1 Jan 2020 19:46:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D228D120047 for ; Wed, 1 Jan 2020 19:46:38 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EDBF3897B for ; Wed, 1 Jan 2020 22:46:21 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2429F1258 for ; Wed, 1 Jan 2020 22:46:37 -0500 (EST) From: Michael Richardson To: ADD Mailing list In-Reply-To: References: <24278.1577216347@localhost> <56E5E3F3-23DD-494F-8C70-E8A5CAC8D0DA@huitema.net> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 03:46:40 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: > However, aside from these and others like them, an unauthenticated discovery > function seems not that useful I agree with you. I think the question is whether we should: 1) find a way to authenticated existing discovery mechanisms. (There are many ways we could go about this) 2) build a new discovery mechanism for DNS servers that includes authentication. Christian has done lots of work in DNS-SD to create new a service discovery mechanism that does not leak the question. I'm not entirely sure that discovering the DNS server is a question we need to avoid leaking, but it might be that it is important to avoid leaking which DNS servers the device would trust. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4NZ5wACgkQgItw+93Q 3WWtxAf/SCCHbJrwcAUbl2w+aDHqLug1oTZSb31VtFfWxppnnqOEGNH5PdrAvBJ8 Q/oz7oD/64eooMfKz7J3IX/OyLi9SwyOZmcJoyiM4l08kZPmbVAUy+vsqVonxOTj 4/ptpFL3XRr94HbrE6CsDDsKRGqKyNEeUOLov13H0D8wUJa+nWQ/olfxFjpkUvVP ZJ6fwRfkIrKqXCO3E7Lpz+8lvDbAlZUsnam2wAsar3xXLkswRzl2M9LO2Zn1GXhe BOeMsiFHNOkBYqa8pF6l9wIGJs+CJx44eoKype6eKhxTvSKBIjcOrts1Gf72RtQa XWW442oAsitL7eOgSppBZGStkD3VmA== =Vffb -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 1 21:28:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C18120044 for ; Wed, 1 Jan 2020 21:28:29 -0800 (PST) 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, MIME_QP_LONG_LINE=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=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 FRoct5-tcooV for ; Wed, 1 Jan 2020 21:28:26 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 7273F120043 for ; Wed, 1 Jan 2020 21:28:26 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id c17so30670581qkg.7 for ; Wed, 01 Jan 2020 21:28:26 -0800 (PST) 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=w+CoQH5iMRT26zWxWvH9MihDQmMN5B3MMQy3rUPHAWc=; b=r0VJVMExH5TAsOVrpbubR2BIzjwFCafeXupipPFOVidd476VBUNYmhAMZ0tJcBmh00 KxoXgLtO6sPUoNPPqJOQskQA9zfQ8ok8OpMVVNC3UKz24IeqSCh7E9KsurJMVZ1Jy86e wWkPvfY6NasuTBF/N587wE6ArOHHR/Xg5lktnrCQFBrdzB7oKsdGabod4/F1GEbryY4l mpQDbkaJuW1mdRZC0Gohc2VqTYDUILTkS3VtBjOm/TXyCvoeZ5SnRbceloKB+F3VzXNu amhfyv8taLIW5imJaeuoBlm/Iuj1NN5+mkeGbkq1HH9paE7b+23HzxIAJsjP4TN7iu91 NPZg== 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=w+CoQH5iMRT26zWxWvH9MihDQmMN5B3MMQy3rUPHAWc=; b=PTuAZ4yxYtsIiCrSO7V4hJQme4cb9r13POYBKrCQoMVsUhh71h8wWbASFLPxgVOcqo 1BzISwP1YMP86jqyhF5TaiWcE9ekCYQxTqLv7JWwtouuXN+zEDSQe7mZ7GW4lSZHp+x4 B0+jw5ek6yCBqA3TyGKEZFr6K3FQxNFG3dO4sutyl8ZkJmTAMY3OhmR79pUNbKJItGgO izH0x568uRMbMeK5IlvDALCN6oXloXDx1CoQcrUL8hgCQtVtcIUkLD3UsJXQZc/dEIBS IbifdrlEI5yGQ56EHZhPOmwsyI1WfjCU7hyf39NfPS9YfKSZ69t7L4jelUrCWoENmk+0 JmFA== X-Gm-Message-State: APjAAAXoBnBiXjl/CWK5YIvp8AH1neZcgrlJzWSPJ4CDDlboiQZa4srs O6005YLBRVdhucUaz7PKDIOAjPtV6ggQmg== X-Google-Smtp-Source: APXvYqxtCTk0AOjN5QKvmkpAB66aQQ5QOM+OlqV1MzsZGWdyq3THuVNH578o2XmYGv3cRXlgRkr0DA== X-Received: by 2002:a05:620a:b19:: with SMTP id t25mr66589821qkg.82.1577942905119; Wed, 01 Jan 2020 21:28:25 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:98aa:be18:e611:5782? ([2601:18b:300:36ee:98aa:be18:e611:5782]) by smtp.gmail.com with ESMTPSA id d23sm16943486qte.32.2020.01.01.21.28.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jan 2020 21:28:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 2 Jan 2020 00:28:23 -0500 Message-Id: References: <32712.1577936797@localhost> Cc: ADD Mailing list In-Reply-To: <32712.1577936797@localhost> To: Michael Richardson X-Mailer: iPad Mail (17E177) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 05:28:29 -0000 There=E2=80=99s no point in authenticating the configuration data. The onl= y way you can trust the resolver is if you are able to configure a trust rel= ationship to it, and validate that it is the resolver with which you have a t= rust relationship. If you can do that, it doesn=E2=80=99t matter if the con= figuration protocol is authenticated. And, importantly, authenticating the= configuration protocol is quite a bit harder. We know this because we=E2=80= =99ve tried. So I would not suggest wasting time revisiting that rathole. Sent from my iPad > On Jan 1, 2020, at 10:46 PM, Michael Richardson wr= ote: >=20 > =EF=BB=BF > Eric Rescorla wrote: >> However, aside from these and others like them, an unauthenticated discov= ery >> function seems not that useful >=20 > I agree with you. > I think the question is whether we should: >=20 > 1) find a way to authenticated existing discovery mechanisms. > (There are many ways we could go about this) >=20 > 2) build a new discovery mechanism for DNS servers that includes > authentication. >=20 > Christian has done lots of work in DNS-SD to create new a service discover= y > mechanism that does not leak the question. I'm not entirely sure that > discovering the DNS server is a question we need to avoid leaking, but > it might be that it is important to avoid leaking which DNS servers the > device would trust. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Thu Jan 2 01:33:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1377D120077 for ; Thu, 2 Jan 2020 01:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BGz7vlzRG9xO for ; Thu, 2 Jan 2020 01:33:39 -0800 (PST) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9B529120071 for ; Thu, 2 Jan 2020 01:33:39 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 259815F40822; Thu, 2 Jan 2020 10:33:37 +0100 (CET) Received: from [172.19.176.181] (p54B8AF9C.dip0.t-ipconnect.de [84.184.175.156]) (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 039EC5F404DF; Thu, 2 Jan 2020 10:33:35 +0100 (CET) From: "Ralf Weber" To: "Rob Sayre" Cc: "Christian Huitema" , "ADD Mailing list" , "John Levine" Date: Thu, 02 Jan 2020 10:33:34 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> In-Reply-To: References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 09:33:42 -0000 Moin! On 1 Jan 2020, at 23:17, Rob Sayre wrote: > Here is a web page about an experiment to detect query data sharing, > including in Europe: > https://blog.benjojo.co.uk/post/ISPs-sharing-DNS-query-data That is just a usual open resolver tool and looking for zombie queries. It tells you nothing about if the ISP is actually sharing that data as within the AS range of an ISP there might be lots of different resolvers used especially if the ISP also serves business and enterprise customers. Also open resolvers are often operated as or on honeypots and thus it somehow is expected that this data shows up at security companies that might replay/look at it. This fact that the ISP might not sell the data is even mentioned at the bottom of the report, but of course not in the headline as this wouldn’t generate clicks. So long -Ralf —-- Ralf Weber From nobody Thu Jan 2 01:50:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4312008D for ; Thu, 2 Jan 2020 01:50:06 -0800 (PST) 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 ZsgtwkmVn9rU for ; Thu, 2 Jan 2020 01:50:03 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F34212007C for ; Thu, 2 Jan 2020 01:50:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nTEvtlFdmqNox+7Fksj/CWjy0x/Ni00YDZQ4n0GPEM8eWHxrE5jqhIjifSvB/irfoOIb3fHtzeq+EIDQLxGPS3rwZIDcjZgDzOz+OTGqrk/k290gAnOEld5jUmYo10EOYeNsfFY+zHu4LQMXn7UOExHPGr4XOy4AtIc60P4IgI922pcqKa8wMUFkAyjum3v6J0Hgusys/h8ZwYbvImVCGmrLzCJCxUu5uOJjtXm7q9MzkjiBeVV+CTdl20R+ufUErtQJkEZry9iBbChPs/8ar0s6jM3WM6lbn6I2Qu/AFfKsb7r4OlE9GozIJKkLzEWVZ0b/9K6PvQ+rpagFLYZUVA== 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=03B1I8HIEG4SyeWhkIGpxGMXw1T1MN5zsdU4FMCATSQ=; b=Id0i0hhxt+T7kTBHztWLPAXnSJ0Gx7GmQu658q0apfVw1gzfCWzs01lSaKrQx+tPv2KlIQODnUdsO8NH6jy4OMv9BlYH4ZfamCqLxsMU+jgEB4gSaltp21R+9n6j1srcqD3/8kPocDNOXchA+VChb7fMlqBeW/C4cqXeKkFifedJksujD/kwzh0DoGibKIoIm17BtHkrsCOMZotrIF+Db4eTNHuGnWjBvDgze1NV5mrheXpMO7g2wZeppslfde3AYItxTzjDLZnb8Eu1Dc3G+AL4fVVLxptz2zcsw6eirNh5L7SBngT7+X4QuhyasK/uyaL67nCV+pdkIu6GI15jyQ== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=03B1I8HIEG4SyeWhkIGpxGMXw1T1MN5zsdU4FMCATSQ=; b=AK4nH68S7DskdMH52yE94CBi6qKh5GadZzqU9P9P+8VlyXtwEy1Uza58ty7Z4jpunTXvhcU4gX7uJJNRf8yor68zEXwjRF2/5AokX+G/jB7MMNyaOJtVpoqamNS8UliKmcn77ZoeNtRTRmU2Upa1uYr+ThybLqY+7EMFkJQSCOE= Received: from DB8PR06MB6521.eurprd06.prod.outlook.com (52.135.60.13) by DB8PR06MB6363.eurprd06.prod.outlook.com (52.135.62.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Thu, 2 Jan 2020 09:49:59 +0000 Received: from DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::dd36:d639:9b7b:e886]) by DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::dd36:d639:9b7b:e886%6]) with mapi id 15.20.2602.012; Thu, 2 Jan 2020 09:49:58 +0000 From: "Winfield, Alister" To: Ralf Weber , Rob Sayre CC: John Levine , ADD Mailing list , Christian Huitema Thread-Topic: [EXTERNAL] Re: [Add] A proposed charter for ABCD Thread-Index: AQHVuZ2DBY8kh0yHlEK6jl8mAPkKZKfJsGGAgAAIloCABAJ0AIAAQC0AgAACmgCAAA+gAIAB3UIAgADIUoCAAqN8AIAAEJ+AgAAhq4CAAAHfgIACyoeAgAAZmQCAAL0BAIAABJUA Date: Thu, 2 Jan 2020 09:49:58 +0000 Message-ID: <3AEC247B-CD61-41BB-A517-20EFDB290714@sky.uk> References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> In-Reply-To: <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk; x-originating-ip: [90.216.150.239] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f8bfd1c-4bc8-447d-a3d3-08d78f692145 x-ms-traffictypediagnostic: DB8PR06MB6363: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(136003)(376002)(396003)(39860400002)(199004)(189003)(45080400002)(6506007)(53546011)(966005)(5660300002)(64756008)(66446008)(76116006)(66946007)(66556008)(478600001)(66476007)(91956017)(2616005)(316002)(86362001)(2906002)(6486002)(54906003)(8676002)(71200400001)(186003)(4326008)(110136005)(81166006)(36756003)(81156014)(26005)(8936002)(33656002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR06MB6363; H:DB8PR06MB6521.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: FDua3kqbHv5166s5aS9BKLVlBGYQmJw3Pu0aCT5MtSYBjGrg8soaKaDl+MkyobYYlek41zp14DWfTaRFfdpam1CBWq78rWB4ThPIAn0qpQi6MYCjZqW2CnMGX02dxeqkMqb7zXKjMDlx6efZkmvo/oHYf8QfFTB4FwsRHCwvVA3KM9S3CfqBDOdBtvQksfZKshKUItoDM2HpeVKcqcdE6Hndh6XZ1c5WIMTbZl1vh010bI0N8VVDJM8P2QzCzhT6BU6BZ0CLKpLZ/B5YpAVcWbQrsawYdDoPafnjudW/DpLXM0khiOxoDE/Q4oD8gRn3cLVUJ3ITGsmbzrRYKozJejBUwCp5p4IwYNPykCchJ4tVeTkVzoJH2CgPZhK1PiXXiwGW3533Lw/MV7svwGo4X0pnZIP2SgGibGuPVtWAb+9jWrI7g4tfunm9Swg5wjtZqwupLa0AxHDroVAldR3FP1j1OL43Ut/uQfUyJZdjSdc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0282CFA4FFE1D644A4E0F4CF6985E90E@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 8f8bfd1c-4bc8-447d-a3d3-08d78f692145 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 09:49:58.8455 (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: HvxhcK4YN7oBoOtd60s2s+lIvUw/5U4YxQ7SW2+9FZ9KTY8gRBDMYv5DNEwp8MGB9iWrgmKpVR1rXYwJoY+yog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR06MB6363 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 09:50:07 -0000 SSBhbHNvIG5vdGUgdGhhdCBzb21lIHJlc29sdmVyIHNvZnR3YXJlIGltcGxlbWVudGF0aW9ucyBp bXByb3ZlIGN1c3RvbWVyIHJlc29sdXRpb24gdGltZXMgYnkgcHJlLWZldGNoaW5nIG5lYXIgY2Fj aGUgZXhwaXJ5IHdpdGhvdXQgYW55IGFzc29jaWF0ZWQgdXNlciByZXF1ZXN0LiBKdXN0IHNvbWV0 aGluZyB0byByZW1lbWJlciB3aGVuIGxvb2tpbmcgYXQgcmVxdWVzdCBwYXR0ZXJucy4NCg0KQWxp c3Rlcg0KDQoNCu+7v09uIDAyLzAxLzIwMjAsIDA5OjM0LCAiQWRkIG9uIGJlaGFsZiBvZiBSYWxm IFdlYmVyIiA8YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRuc0BmbDFnZXIuZGU+ IHdyb3RlOg0KDQogICAgTW9pbiENCg0KICAgIE9uIDEgSmFuIDIwMjAsIGF0IDIzOjE3LCBSb2Ig U2F5cmUgd3JvdGU6DQogICAgPiBIZXJlIGlzIGEgd2ViIHBhZ2UgYWJvdXQgYW4gZXhwZXJpbWVu dCB0byBkZXRlY3QgcXVlcnkgZGF0YSBzaGFyaW5nLA0KICAgID4gaW5jbHVkaW5nIGluIEV1cm9w ZToNCiAgICA+IGh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRmJsb2cuYmVuam9qby5jby51ayUyRnBvc3QlMkZJU1BzLXNoYXJp bmctRE5TLXF1ZXJ5LWRhdGEmYW1wO2RhdGE9MDIlN0MwMSU3Q2FsaXN0ZXIud2luZmllbGQlNDBz a3kudWslN0M3NzYwYTIyMmRjN2E0ZDI3YmJjNjA4ZDc4ZjY2ZTQyYSU3QzY4Yjg2NWQ1Y2YxODRi MmI4MmE0YTRlZGRiOWM1MjM3JTdDMCU3QzAlN0M2MzcxMzU1NDQzOTg0NTA1NjEmYW1wO3NkYXRh PU0yZ0I4JTJGVXBidVNHanN0NU91b3BqMFNDSm9zSXhJTEVhNmlrUEV4NyUyQmk0JTNEJmFtcDty ZXNlcnZlZD0wDQogICAgVGhhdCBpcyBqdXN0IGEgdXN1YWwgb3BlbiByZXNvbHZlciB0b29sIGFu ZCBsb29raW5nIGZvciB6b21iaWUgcXVlcmllcy4NCiAgICBJdCB0ZWxscyB5b3Ugbm90aGluZyBh Ym91dCBpZiB0aGUgSVNQIGlzIGFjdHVhbGx5IHNoYXJpbmcgdGhhdCBkYXRhIGFzDQogICAgd2l0 aGluIHRoZSBBUyByYW5nZSBvZiBhbiBJU1AgdGhlcmUgbWlnaHQgYmUgbG90cyBvZiBkaWZmZXJl bnQgcmVzb2x2ZXJzDQogICAgdXNlZCBlc3BlY2lhbGx5IGlmIHRoZSBJU1AgYWxzbyBzZXJ2ZXMg YnVzaW5lc3MgYW5kIGVudGVycHJpc2UgY3VzdG9tZXJzLg0KDQogICAgQWxzbyBvcGVuIHJlc29s dmVycyBhcmUgb2Z0ZW4gb3BlcmF0ZWQgYXMgb3Igb24gaG9uZXlwb3RzIGFuZCB0aHVzIGl0DQog ICAgc29tZWhvdyBpcyBleHBlY3RlZCB0aGF0IHRoaXMgZGF0YSBzaG93cyB1cCBhdCBzZWN1cml0 eSBjb21wYW5pZXMgdGhhdA0KICAgIG1pZ2h0IHJlcGxheS9sb29rIGF0IGl0Lg0KDQogICAgVGhp cyBmYWN0IHRoYXQgdGhlIElTUCBtaWdodCBub3Qgc2VsbCB0aGUgZGF0YSBpcyBldmVuIG1lbnRp b25lZCBhdCB0aGUNCiAgICBib3R0b20gb2YgdGhlIHJlcG9ydCwgYnV0IG9mIGNvdXJzZSBub3Qg aW4gdGhlIGhlYWRsaW5lIGFzIHRoaXMgd291bGRu4oCZdA0KICAgIGdlbmVyYXRlIGNsaWNrcy4N Cg0KICAgIFNvIGxvbmcNCiAgICAtUmFsZg0KICAgIOKAlC0tDQogICAgUmFsZiBXZWJlcg0KDQog ICAgLS0NCiAgICBBZGQgbWFpbGluZyBsaXN0DQogICAgQWRkQGlldGYub3JnDQogICAgaHR0cHM6 Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGYWRkJmFtcDtkYXRhPTAyJTdD MDElN0NhbGlzdGVyLndpbmZpZWxkJTQwc2t5LnVrJTdDNzc2MGEyMjJkYzdhNGQyN2JiYzYwOGQ3 OGY2NmU0MmElN0M2OGI4NjVkNWNmMTg0YjJiODJhNGE0ZWRkYjljNTIzNyU3QzAlN0MwJTdDNjM3 MTM1NTQ0Mzk4NDUwNTYxJmFtcDtzZGF0YT1sTmRxYTBqZDg0MjJaWWdxMVRzcHZ1MnBKUm4zWW5s MlFLU1Y1ZFR0NWtjJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBUaGlz IGVtYWlsIGlzIGZyb20gYW4gZXh0ZXJuYWwgc291cmNlLiBQbGVhc2UgZG8gbm90IG9wZW4gYXR0 YWNobWVudHMgb3IgY2xpY2sgbGlua3MgZnJvbSBhbiB1bmtub3duIG9yIHN1c3BpY2lvdXMgb3Jp Z2luLiBQaGlzaGluZyBhdHRlbXB0cyBjYW4gYmUgcmVwb3J0ZWQgYnkgc2VuZGluZyB0aGVtIHRv IHBoaXNoaW5nQHNreS51ayBhcyBhdHRhY2htZW50cy4gVGhhbmsgeW91DQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQoNCkluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cyBtYXkgYmUgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBleGNs dXNpdmVseSBmb3IgdGhlIGFkZHJlc3NlZS4gVGhlIHZpZXdzIGV4cHJlc3NlZCBtYXkgbm90IGJl IG9mZmljaWFsIHBvbGljeSwgYnV0IHRoZSBwZXJzb25hbCB2aWV3cyBvZiB0aGUgb3JpZ2luYXRv ci4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4gWW91 IHNob3VsZCBub3QgcmVwcm9kdWNlLCBkaXN0cmlidXRlLCBzdG9yZSwgcmV0cmFuc21pdCwgdXNl IG9yIGRpc2Nsb3NlIGl0cyBjb250ZW50cyB0byBhbnlvbmUuIFBsZWFzZSBub3RlIHdlIHJlc2Vy dmUgdGhlIHJpZ2h0IHRvIG1vbml0b3IgYWxsIGUtbWFpbCBjb21tdW5pY2F0aW9uIHRocm91Z2gg b3VyIGludGVybmFsIGFuZCBleHRlcm5hbCBuZXR3b3Jrcy4gU0tZIGFuZCB0aGUgU0tZIG1hcmtz IGFyZSB0cmFkZW1hcmtzIG9mIFNreSBMaW1pdGVkIGFuZCBTa3kgSW50ZXJuYXRpb25hbCBBRyBh bmQgYXJlIHVzZWQgdW5kZXIgbGljZW5jZS4NCg0KU2t5IFVLIExpbWl0ZWQgKFJlZ2lzdHJhdGlv biBOby4gMjkwNjk5MSksIFNreS1Jbi1Ib21lIFNlcnZpY2UgTGltaXRlZCAoUmVnaXN0cmF0aW9u IE5vLiAyMDY3MDc1KSwgU2t5IFN1YnNjcmliZXJzIFNlcnZpY2VzIExpbWl0ZWQgKFJlZ2lzdHJh dGlvbiBOby4gMjM0MDE1MCkgYW5kIFNreSBDUCBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDk1 MTMyNTkpIGFyZSBkaXJlY3Qgb3IgaW5kaXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBMaW1pdGVk IChSZWdpc3RyYXRpb24gTm8uIDIyNDc3MzUpLiBBbGwgb2YgdGhlIGNvbXBhbmllcyBtZW50aW9u ZWQgaW4gdGhpcyBwYXJhZ3JhcGggYXJlIGluY29ycG9yYXRlZCBpbiBFbmdsYW5kIGFuZCBXYWxl cyBhbmQgc2hhcmUgdGhlIHNhbWUgcmVnaXN0ZXJlZCBvZmZpY2UgYXQgR3JhbnQgV2F5LCBJc2xl d29ydGgsIE1pZGRsZXNleCBUVzcgNVFEDQo= From nobody Thu Jan 2 02:00:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED971200A3 for ; Thu, 2 Jan 2020 02:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CrCslQoNYkqu for ; Thu, 2 Jan 2020 02:00:36 -0800 (PST) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD912002E for ; Thu, 2 Jan 2020 02:00:36 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 9DC395F40B77; Thu, 2 Jan 2020 11:00:35 +0100 (CET) Received: from [172.19.176.181] (p54B8AF9C.dip0.t-ipconnect.de [84.184.175.156]) (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 310D65F404CA; Thu, 2 Jan 2020 11:00:33 +0100 (CET) From: "Ralf Weber" To: "Ted Lemon" Cc: "Michael Richardson" , "ADD Mailing list" Date: Thu, 02 Jan 2020 11:00:32 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <32712.1577936797@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 10:00:38 -0000 Moin! On 2 Jan 2020, at 6:28, Ted Lemon wrote: > There=E2=80=99s no point in authenticating the configuration data. Th= e = > only way you can trust the resolver is if you are able to configure a = > trust relationship to it, and validate that it is the resolver with = > which you have a trust relationship. If you can do that, it doesn=E2=80= =99t = > matter if the configuration protocol is authenticated. And, = > importantly, authenticating the configuration protocol is quite a bit = > harder. We know this because we=E2=80=99ve tried. So I would not su= ggest = > wasting time revisiting that rathole. Can you define trust relationship / authenticating configuration data. = Depending on how you define that the solution is either obvious or = impossible. As an ops guy and non native english speaker I often = struggle with abstractions, so let me give you an concrete example you = can hopefully give an answer on: - A router sends a client an PvD RA as defined in = (draft-bruneau-intarea-provisioning-domains - = https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/= = ) with FQDN content of pvd.myisp.net. - My system retrieves https://pvd.myisp.net/.well-known/pvd and can = DNSSEC validate the domain and the HTTP certificate - In the JSON blob retrieved contains the following keys (see = draft-pauly-dprive-adaptive-dns-privacy - = https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/= ?include_text=3D1 = ): dohuri: https://doh.myisp.net/dns-query requireDNSFiltering: True dnsFilteredZones: =E2=80=9C.=E2=80=9D I can again DNSSEC validate the domain and the HTTP certificate using = they key stores available with my system. Is that authenticated? Is there a trust relationship? So long -Ralf =E2=80=94-- Ralf Weber From nobody Thu Jan 2 05:12:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C912009E for ; Thu, 2 Jan 2020 05:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNIdW_pBTwXU for ; Thu, 2 Jan 2020 05:12:53 -0800 (PST) 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 78EFF12008F for ; Thu, 2 Jan 2020 05:12:53 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id h23so40663482ljc.8 for ; Thu, 02 Jan 2020 05:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IXgJzxU4BE/dsIh2qf//jG2bxIMkiZswwYFfkZFJZr8=; b=oVUFGlHwFsL0f4rGj3EkOTtxf7qvoj0GYdFws+xXzz79dzbg4arBt3/YTyMC9GYJIr vU09GZ9yy2FgVSCTC+TZBo2lVFTna2WbWJeZ/INpOtse1/dCjpgnkxRpOIP3YWBOwUCX pMQC28V4WGkhepVtvt9oynXekxzc0imAkMZgEgtzUviRrmmAGzv8cG38GVXxS9HImRlH N7/LWBLgdiV9Z3xxfHY7FppXBdUQlhTwMuoEn7OxTWNn9S1tbDyVhQMpjF9rbspquz8z Fs9JXUEp5fzYcXrL18z4CFpDmxN8CW0BxNK4TM/nexsPZl6o3cdaDLD0z9XG0eFmi3ys QGpg== 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=IXgJzxU4BE/dsIh2qf//jG2bxIMkiZswwYFfkZFJZr8=; b=aHcgzSIlFyPnl2KMfTKQ9iofmelv9AEsFxdMNjRzFZUdiPb29GN1KNL/FHO7P5YNrU 90HDIwhlB0RvtH2r7idjv6hfJpQ+CMTDL6l5QqrMHjXMy+fCrC4kD8VUj2+O53Fj7rcs xT2ruQuq01H5D802uW4k2ort14gUWkqwW0+2Hxqcjc2GlAqE8YwooxX8RlWtDXRSGs4E hHqKgsdLir86Kp9GHjWC4iNHXUM6GgVMvVJhjYcGiWC0rkIviYE+pLz55+jWzR18cBT8 6h6EQEWfxeVv1YYUvGMX9oKiBqe/H3TRMLChb/Xp49cJD87yknfcDeyii94QUrofy6sH 229g== X-Gm-Message-State: APjAAAV18c8CwqiG9JTpddoX7LQOd/Xc3VcifWMZ+Q9zWwdAN1WGDmP8 G052urfF7mcWTPQs4Wx1gLUpVV7qYd293Du8v+Solh48aj4= X-Google-Smtp-Source: APXvYqw9CDSIyYw5BQrFS/SOo69l9dm4BoGBbe3I+AcPopiyKaVZ16celekojYLENNzJGgK/pWsnExBcldgHpyAB7ug= X-Received: by 2002:a2e:870b:: with SMTP id m11mr47246544lji.93.1577970771767; Thu, 02 Jan 2020 05:12:51 -0800 (PST) MIME-Version: 1.0 References: <32712.1577936797@localhost> In-Reply-To: From: Eric Rescorla Date: Thu, 2 Jan 2020 05:12:14 -0800 Message-ID: To: Ralf Weber Cc: Ted Lemon , Michael Richardson , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000514899059b27f3c1" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 13:12:57 -0000 --000000000000514899059b27f3c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 2:00 AM Ralf Weber wrote: > Moin! > > On 2 Jan 2020, at 6:28, Ted Lemon wrote: > > > There=E2=80=99s no point in authenticating the configuration data. Th= e > > only way you can trust the resolver is if you are able to configure a > > trust relationship to it, and validate that it is the resolver with > > which you have a trust relationship. If you can do that, it doesn=E2= =80=99t > > matter if the configuration protocol is authenticated. And, > > importantly, authenticating the configuration protocol is quite a bit > > harder. We know this because we=E2=80=99ve tried. So I would not su= ggest > > wasting time revisiting that rathole. > Can you define trust relationship / authenticating configuration data. > Depending on how you define that the solution is either obvious or > impossible. As an ops guy and non native english speaker I often > struggle with abstractions, so let me give you an concrete example you > can hopefully give an answer on: > > - A router sends a client an PvD RA as defined in > (draft-bruneau-intarea-provisioning-domains - > https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ > ) with FQDN content of pvd.myisp.net. > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can > DNSSEC validate the domain and the HTTP certificate > - In the JSON blob retrieved contains the following keys (see > draft-pauly-dprive-adaptive-dns-privacy - > > https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/= ?include_text=3D1 > ): > dohuri: https://doh.myisp.net/dns-query > requireDNSFiltering: True > dnsFilteredZones: =E2=80=9C.=E2=80=9D > I can again DNSSEC validate the domain and the HTTP certificate using > they key stores available with my system. > > Is that authenticated? Is there a trust relationship? > No, because the first step wasn't authenticated. An attacker could have forged the RA. -Ekr > So long > -Ralf > =E2=80=94-- > Ralf Weber > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000514899059b27f3c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 2:00 AM Ralf W= eber <dns@fl1ger.de> wrote:
<= /div>
Moin!

On 2 Jan 2020, at 6:28, Ted Lemon wrote:

> There=E2=80=99s no point in authenticating the configuration data.=C2= =A0 =C2=A0The
> only way you can trust the resolver is if you are able to configure a =
> trust relationship to it, and validate that it is the resolver with > which you have a trust relationship.=C2=A0 If you can do that, it does= n=E2=80=99t
> matter if the configuration protocol is authenticated.=C2=A0 =C2=A0And= ,
> importantly, authenticating the configuration protocol is quite a bit =
> harder.=C2=A0 =C2=A0We know this because we=E2=80=99ve tried.=C2=A0 = =C2=A0So I would not suggest
> wasting time revisiting that rathole.
Can you define trust relationship / authenticating configuration data.
Depending on how you define that the solution is either obvious or
impossible. As an ops guy and non native english speaker I often
struggle with abstractions, so let me give you an concrete example you
can hopefully give an answer on:

- A router sends a client an PvD RA as defined in
(draft-bruneau-intarea-provisioning-domains -
https://datatracker.ietf.or= g/doc/draft-ietf-intarea-provisioning-domains/
) with FQDN content of pvd.myisp.net.
- My system retrieves https://pvd.myisp.net/.well-known/pvd= and can
DNSSEC validate the domain and the HTTP certificate
- In the JSON blob retrieved contains the following keys (see
draft-pauly-dprive-adaptive-dns-privacy -
https://da= tatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/?include_tex= t=3D1
):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dohuri: https://doh.myisp.net/dns-query
=C2=A0 =C2=A0 =C2=A0 =C2=A0 requireDNSFiltering: True
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsFilteredZones: =E2=80=9C.=E2=80=9D
I can again DNSSEC validate the domain and the HTTP certificate using
they key stores available with my system.

Is that authenticated? Is there a trust relationship?


So long
-Ralf
=E2=80=94--
Ralf Weber

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000514899059b27f3c1-- From nobody Thu Jan 2 06:10:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737051200C1 for ; Thu, 2 Jan 2020 06:10:53 -0800 (PST) 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, MIME_QP_LONG_LINE=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=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 I5AKn5ryu4Ei for ; Thu, 2 Jan 2020 06:10:51 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 45BDF1200B7 for ; Thu, 2 Jan 2020 06:10:51 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id g1so27825735qtr.13 for ; Thu, 02 Jan 2020 06:10:51 -0800 (PST) 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=uz3R658Q4Fk3rZqtugjiYIbba0RV3LYkBVpAvFS/UTE=; b=S0SaPo8aR4j69+eGcOoaJb9OuegOm1YaciN4eBSJ5zEN+S9Hlqv/FNywjHgJG8W9gx 3o7OTrziLDBTnBQw5zdtIj29UNpLJTnCis57OlOLqAszU2k8qMkZs0cZohYYNY8U/VEx 2mhbXsp2WdDHpWpklaQEfo5wRbKIKq7MrC8KTSwJX6e0m1aAQZstUCWqoozG5F3gtJyI xpLX3RQRbQkQHdzI0Qep/0kr6Rx+yZ2m+fcbOcMRHSgEL0TK842WD4GEM9aHpGxVvq16 49JM9ae26rDn9lVfe9eXueWXYgRxJvt0wTYLnsheuK2ROf3+7nkLVwp/YQukHu6duwbA FKlA== 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=uz3R658Q4Fk3rZqtugjiYIbba0RV3LYkBVpAvFS/UTE=; b=BsA7m6tSSQNiWaNY0FeJcu8TLhC6MBb4AqreBJ0V+66tF4ABQXfokarA9/p+/53eW0 PArPrbLxCsTpabhhmFGcUj4iZ7HImZj7sloRPC+deSrkYPeM6AZIIpqqWQu8/rIJ/sEf 6MJ0wgH+LLlRlQMlsPrkRUEMXEBOW4hHdKQSJp1SXiuWAFBdPfK2PBShSxZOsM+GGFqd sgE2RPa4QlJqWuElduzI97sgBysUPJuC5UczG+ZdzjvC0bayRvtLM4VqUpDo+y/0Iova FP8z+N85d4wU0VyJdjt3UArmR+C1ATcpv+MeJZGPudi9e/XYVqg8d4IwQ/vHPfegBpCN D/ow== X-Gm-Message-State: APjAAAWbPjN31q0imGtuXkMOolrp2/TcOrYKBzxpq/GsAAecrczp1smV 8f4y40cGKdpr6dlePBzxfjP160ByARpKfw== X-Google-Smtp-Source: APXvYqyWan+/xSZr1XuQPH0ftkcJ7rEMWNXcm9nHL7TnqOiFsvmcRqtlusUQzwXRhWHzoUNcQXW+BQ== X-Received: by 2002:ac8:3463:: with SMTP id v32mr58597268qtb.8.1577974250367; Thu, 02 Jan 2020 06:10:50 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:98aa:be18:e611:5782? ([2601:18b:300:36ee:98aa:be18:e611:5782]) by smtp.gmail.com with ESMTPSA id n1sm14997833qkk.122.2020.01.02.06.10.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jan 2020 06:10:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 2 Jan 2020 09:10:48 -0500 Message-Id: <573C729A-F27E-4230-BB0B-94533B6CBC5B@fugue.com> References: Cc: Michael Richardson , ADD Mailing list In-Reply-To: To: Ralf Weber X-Mailer: iPad Mail (17E177) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 14:10:54 -0000 On Jan 2, 2020, at 5:00 AM, Ralf Weber wrote: > Can you define trust relationship / authenticating configuration data. Dep= ending on how you define that the solution is either obvious or impossible. A= s an ops guy and non native english speaker I often struggle with abstractio= ns, so let me give you an concrete example you can hopefully give an answer o= n: Good questions, thanks. > - A router sends a client an PvD RA as defined in (draft-bruneau-intarea-p= rovisioning-domains - https://datatracker.ietf.org/doc/draft-ietf-intarea-pr= ovisioning-domains/ ) with FQDN content of pvd.myisp.net. > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can DNSSEC= validate the domain and the HTTP certificate > - In the JSON blob retrieved contains the following keys (see draft-pauly-= dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-pauly-d= prive-adaptive-dns-privacy/?include_text=3D1 ): > dohuri: https://doh.myisp.net/dns-query > requireDNSFiltering: True > dnsFilteredZones: =E2=80=9C.=E2=80=9D > I can again DNSSEC validate the domain and the HTTP certificate using they= key stores available with my system. >=20 > Is that authenticated? Is there a trust relationship? No. You have no more reason to trust that than you do any other random HTT= PS-authenticated web site that you might try to access. When you go to htt= ps://www.badguy.com, you know that it=E2=80=99s really www.badguy.com becaus= e the TLS cert validates, and maybe the DNSSEC validated, but you /don=E2=80= =99t/ have any reason to trust answers you get from that site. That=E2=80=99s why I say there=E2=80=99s no reason to go through any extra b= other. In order to have a trust relationship, I need to have configured a l= ist of sites I trust as DNS resolvers. This is independent of the RA I rece= ive, or the DHCP message I receive. Then when I get an RA or a DHCP message asserting the availability of a DNS r= esolver, if I have a trust relationship with that resolver, and I can valida= te the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted resolver.=E2= =80=9D Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted resolver.=E2=80=9D I= t=E2=80=99s the pre-established trust relationship that makes it trusted, no= t some assertion I get from the network about it being trustworthy. E.g., suppose I trust the SLA from my ISP. I believe that my ISP will not s= noop on my DNS data, and I want to use their resolver. If their resolver i= s using DoH or DoT, then I can list the domain name(s) of their resolver in m= y list of trusted resolvers. When I am offered one of these resolvers, I c= an validate that I=E2=80=99m actually communicating with it, by validating t= he TLS cert, and then I can trust it, because of that pre-established trust r= elationship, not because of any assertion the network made about its trustwo= rthiness. Absent some kind of out-of-band trust establishment process like this, there= can=E2=80=99t be a trust relationship with a resolver. From nobody Thu Jan 2 06:21:32 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59A91200B1 for ; Thu, 2 Jan 2020 06:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8lt-TkdsfUW2 for ; Thu, 2 Jan 2020 06:21:27 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id A1730120091 for ; Thu, 2 Jan 2020 06:21:27 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 445565F4078E; Thu, 2 Jan 2020 15:21:26 +0100 (CET) Received: from [172.19.176.181] (p54B8AF9C.dip0.t-ipconnect.de [84.184.175.156]) (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 27F325F404E7; Thu, 2 Jan 2020 15:21:25 +0100 (CET) From: "Ralf Weber" To: "Ted Lemon" Cc: "Michael Richardson" , "ADD Mailing list" , "Eric Rescorla" Date: Thu, 02 Jan 2020 15:21:24 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <62F6EEE6-E434-4C1E-87CA-D6B13C1D05C1@fl1ger.de> In-Reply-To: <573C729A-F27E-4230-BB0B-94533B6CBC5B@fugue.com> References: <573C729A-F27E-4230-BB0B-94533B6CBC5B@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 14:21:30 -0000 Moin! On 2 Jan 2020, at 15:10, Ted Lemon wrote: > No. You have no more reason to trust that than you do any other > random HTTPS-authenticated web site that you might try to access. > When you go to https://www.badguy.com, you know that it’s really > www.badguy.com because the TLS cert validates, and maybe the DNSSEC > validated, but you /don’t/ have any reason to trust answers you get > from that site. Well that is sort of true. So let me reword the rest of your text to be more accurate ;-) : That’s why I say there’s no reason to go through any extra bother. In order to have a trust relationship, I need to have configured a list of sites I trust as web sites This is independent of the link I receive, or the URL I receive. Then when I get a link or URL asserting the availability of a web site, if I have a trust relationship with that web stie, and I can validate the cert upon connecting, then it’s a “trusted web site.” Otherwise, it’s an “untrusted web site.” It’s the pre-established trust relationship that makes it trusted, not some assertion I get from the some linke or URL about it being trustworthy. E.g., suppose I trust the SLA from my web site operator. I believe that my web site will not sell my private data, and I want to use their content. If they are using DNSSEC and have a valid certificat, then I can list the domain name(s) of that website in my list of trusted websites. When I am offered one of these websites, I can validate that I’m actually communicating with it, by validating the TLS cert, and then I can trust it, because of that pre-established trust relationship, not because of any assertion from an link . Absent some kind of out-of-band trust establishment process like this, there can’t be a trust relationship with a web site. I’ll leave it as this and have a good night of sleep before my next response. So long -Ralf —-- Ralf Weber From nobody Thu Jan 2 07:56:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4681200F9 for ; Thu, 2 Jan 2020 07:56:31 -0800 (PST) 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 IH7k7PygSLfW for ; Thu, 2 Jan 2020 07:56:29 -0800 (PST) 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 95A2C1200EC for ; Thu, 2 Jan 2020 07:56:29 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47pXhV2vLGzF55; Thu, 2 Jan 2020 16:56:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1577980586; bh=y1TAXg+cqVTuWY5eoW9OGnLmOWWZ10vtEfGqo6bW0w8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CHegXE0nBa7U1rVXHxAjnDdYgfYBiMUYYajO5HXEmowCRcdEiNDsj2NX1Q1HX53cy qVp5Ad/ShoLLl63Qp4EQItFPNN+wsGXWlq1TAP81BBF8DC24vV3tlQT/AXemDZukZG DFGYd9MHzyrZsZwHc3k+B7qB7hVR8+df7dmeO0Hc= 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 vKFBnjTJZsmw; Thu, 2 Jan 2020 16:56:24 +0100 (CET) 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, 2 Jan 2020 16:56:24 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4ECCF6001422; Thu, 2 Jan 2020 10:56:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4B1F165E47; Thu, 2 Jan 2020 10:56:23 -0500 (EST) Date: Thu, 2 Jan 2020 10:56:23 -0500 (EST) From: Paul Wouters To: Eric Rescorla cc: ADD Mailing list In-Reply-To: Message-ID: References: <32712.1577936797@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 15:56:32 -0000 On Thu, 2 Jan 2020, Eric Rescorla wrote: > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can > DNSSEC validate the domain and the HTTP certificate > - In the JSON blob retrieved contains the following keys (see > draft-pauly-dprive-adaptive-dns-privacy - > https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/?include_text=1 > ): >         dohuri: https://doh.myisp.net/dns-query >         requireDNSFiltering: True >         dnsFilteredZones: “.” > I can again DNSSEC validate the domain and the HTTP certificate using > they key stores available with my system. > > Is that authenticated? Is there a trust relationship? > > > No, because the first step wasn't authenticated. An attacker could have forged the RA. That does not matter if you have a preloaded DNSSEC root trust anchor, and the received configuration doesn't include any domain overrides, which would be what you would expect for a hotel or coffee shop wifi? (really, all non-enterprise, non-home networks you join) However, that only relates to the authenticated part. An attacker could still have rerouted your encrypted DNS queries through their server, where they relay and monitor. And so yes, the privacy would still be lost. But then again, if you are concerned about that, why ever accept a remote config for an encrypted DNS server? Paul From nobody Thu Jan 2 10:27:17 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05AB1200BA for ; Thu, 2 Jan 2020 10:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNTkA-B8PuGJ for ; Thu, 2 Jan 2020 10:27:13 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450: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 8C1651201A3 for ; Thu, 2 Jan 2020 10:27:12 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id y6so33568000lji.0 for ; Thu, 02 Jan 2020 10:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JH3Sw24UB24X4ijHZVPYaJGKKpMilEaOvqScQZia0Xg=; b=z3H+k1+1iSejqUA39DmOdiZTF91bgQDYC0mh0fRNFq14FSqz3ijChNd01isx4E5vNm jh1ESZo+CkMl1BdDOb2QYWQxDD99p+Y3W6QYhjKXofBJ3hGJihqn7LADD4fDsb2CFp/l ZOeGTiOGxU+edIDQF5UKHVfBsD9bzX2D68M3pdqnDFZHgd1H3Gqe2HWVrUGindvtLv7d d1+1RbTwBaot6Mv18LPJi5R7WmcO4PbpPmmDuuKAmUK27x1mK2crtC0Ii+3a2WbWUWVt 9kvOILBlUBZJwMQIagjjZ4sPAKO8nby8nw0lIama3q7fHjdz52wEho1xUMXuKcx9rBmX XzxA== 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=JH3Sw24UB24X4ijHZVPYaJGKKpMilEaOvqScQZia0Xg=; b=Vgj6BMX/+jyIYPZdzpr8etCaR825jk+l5fKNaOdW1PZFsuNvAWrSgOYU8WEenK2ph/ pbFyF8wM2Gf5UMOcnVQux4FQ2fbKX15/HdvWYnPXaCai0Eiuw4M57dmdBWdc4iM8PIBh 5HkuAG+7A4zpz5oXQ078nC/5I/UeU4hZkomZbhUnC1hQqhIxozCjPlwrscvcxBHNfYWO bIoHynDTyQGU2DxLu974V7h7T8ttspdJ8oDtSdc5UnPgreyk38HeQ6efmnXjkxs6Dlm5 AQY8IwrVE21KWHOKdYCGpeNNe5FNogXIut7ftdWrJ3gutF6PaaExuYwUeoRyfHv8Gtg/ HGLw== X-Gm-Message-State: APjAAAUFvZmX80kjcGtBCR8Rr4mBxM8vKgKTmuhbBYcX3bqCcPWjR0YH +IOlfoPPTI07gD9V89LsXsGNod/Bets7pLnUohYkaALSPis= X-Google-Smtp-Source: APXvYqwxV0l4SWFDPhx7liwWmb0hTNmv8pqqzxprkIB3F8t87MNSaBPphFjUen0TdvPjMFn1FvwxwI00avZsChOGwAk= X-Received: by 2002:a05:651c:239:: with SMTP id z25mr50194635ljn.48.1577989630697; Thu, 02 Jan 2020 10:27:10 -0800 (PST) MIME-Version: 1.0 References: <32712.1577936797@localhost> In-Reply-To: From: Eric Rescorla Date: Thu, 2 Jan 2020 10:26:34 -0800 Message-ID: To: Paul Wouters Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000065b4e7059b2c5722" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 18:27:15 -0000 --00000000000065b4e7059b2c5722 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 7:56 AM Paul Wouters wrote: > On Thu, 2 Jan 2020, Eric Rescorla wrote: > > > - My system retrieves https://pvd.myisp.net/.well-known/pvd and > can > > DNSSEC validate the domain and the HTTP certificate > > - In the JSON blob retrieved contains the following keys (see > > draft-pauly-dprive-adaptive-dns-privacy - > > > https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/= ?include_text=3D1 > > ): > > dohuri: https://doh.myisp.net/dns-query > > requireDNSFiltering: True > > dnsFilteredZones: =E2=80=9C.=E2=80=9D > > I can again DNSSEC validate the domain and the HTTP certificate > using > > they key stores available with my system. > > > > Is that authenticated? Is there a trust relationship? > > > > > > No, because the first step wasn't authenticated. An attacker could have > forged the RA. > > That does not matter if you have a preloaded DNSSEC root trust anchor, > and the received configuration doesn't include any domain overrides, > which would be what you would expect for a hotel or coffee shop wifi? > (really, all non-enterprise, non-home networks you join) > > However, that only relates to the authenticated part. An attacker could > still have rerouted your encrypted DNS queries through their server, > where they relay and monitor. And so yes, the privacy would still be > lost. But then again, if you are concerned about that, why ever accept > a remote config for an encrypted DNS server? > I think in general you wouldn't, but as I noted in a previous message, there are a few special cases this might make sense -Ekr > Paul > --00000000000065b4e7059b2c5722 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 7:56 AM Paul W= outers <paul@nohats.ca> wrote:<= br>
On Thu, 2 Jan 20= 20, Eric Rescorla wrote:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- My system retrieves https://pv= d.myisp.net/.well-known/pvd and can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DNSSEC validate the domain and the HTTP cert= ificate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- In the JSON blob retrieved contains the fo= llowing keys (see
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-pauly-dprive-adaptive-dns-privacy - >=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-pauly-dprive-ad= aptive-dns-privacy/?include_text=3D1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 dohuri: h= ttps://doh.myisp.net/dns-query
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 requireDNSFilter= ing: True
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsFilteredZones= : =E2=80=9C.=E2=80=9D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I can again DNSSEC validate the domain and t= he HTTP certificate using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0they key stores available with my system. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Is that authenticated? Is there a trust rela= tionship?
>
>
> No, because the first step wasn't authenticated. An attacker could= have forged the RA.

That does not matter if you have a preloaded DNSSEC root trust anchor,
and the received configuration doesn't include any domain overrides, which would be what you would expect for a hotel or coffee shop wifi?
(really, all non-enterprise, non-home networks you join)

However, that only relates to the authenticated part. An attacker could
still have rerouted your encrypted DNS queries through their server,
where they relay and monitor. And so yes, the privacy would still be
lost. But then again, if you are concerned about that, why ever accept
a remote config for an encrypted DNS server?

I think in general you wouldn't, but as I noted in a previous mes= sage, there are a few special cases this might make sense

-Ekr


Paul
--00000000000065b4e7059b2c5722-- From nobody Thu Jan 2 12:58:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D547120154 for ; Thu, 2 Jan 2020 12:58:44 -0800 (PST) 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 Xsvmw_sgypaL for ; Thu, 2 Jan 2020 12:58:42 -0800 (PST) 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 96660120143 for ; Thu, 2 Jan 2020 12:58:42 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id c16so9660736ioh.6 for ; Thu, 02 Jan 2020 12:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K3CzXAH6jQ7DyA2rjg4/gbrvJn0Oj+hCaMuzIvKvQN4=; b=Z5ZkdI/QdedZ55qJ22y1UaTvo7mE14vyrpOS8ced4FvGJm8sKjJptQQnTE6IgEG6P4 OQOtP1qYAMAyAYDlFpuCpQNO2hl8uhZqVEt9RvcLXQBEaHONwWnVWuQPAoB4eJagEcly LMHDxcPLMpACQGMXI7Xpd/s6MV2sY7VsX3dhzeYBfItmrVjiq2kSSKPuwVtJhQ1IQQyT jV8Skb/0qCFvLq25z9WB6hJkaiHTh1t0qeYcft2wxtie+259wMamTKf+uzdOpqvV4nHd pps04kBLhgvxzfuFw1XGBX3Vlh3KPDRUA5PSfzbFDgRN45kPNPLaeu/LGOuVn3b3uda2 KRmQ== 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=K3CzXAH6jQ7DyA2rjg4/gbrvJn0Oj+hCaMuzIvKvQN4=; b=U/EbA3B38w/3Pj+/z7JxvjzulrIqco+4vIXp5IIAM6eH2BKsysufB2EOP3Dy9RkT/5 QOqzE9SJeenk2DjDQFJVqOV55MmQgoRUfsZMSx0gji747C1LOJqAvyLDAtMADhj4W1en 0sSJxoS/VR9u2RYs7jnauTYVurjkU0OAsupgc9C4sLHCMjz2z/OYzGBGDOgpw7IVOiJC 7TyLQoTLdoB9gaHRqHvyDZ1Z0ewCp8o9ZtpMiXL9EjdfhNuS1dM2I5Qn3ry1hAZkxb9a T/YVbGT261v8PztojRFDpkjGoJQbbJWXBiUcRHwayqJ14ezeSt6DG9TfP/jqEjUX/GDB eBQg== X-Gm-Message-State: APjAAAUQ0uvH6+f8g5a3qbygz2iusB0Eewr4eSLn6J5kucOOiJ84ec5c JyZz2yjLlfXm1tT7VcynWoPs/bUPfcDbjYepl3Tp8g== X-Google-Smtp-Source: APXvYqxmKFWr9KpYJ1m2khd5H2S8+AJ1QA/2qMv1ejtjKGgMHa+7aVwoQ4Z4k6sCoQlgLwVUquDDmIW+beotGioTpZQ= X-Received: by 2002:a6b:d219:: with SMTP id q25mr43336618iob.49.1577998721688; Thu, 02 Jan 2020 12:58:41 -0800 (PST) MIME-Version: 1.0 References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> In-Reply-To: <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> From: Rob Sayre Date: Thu, 2 Jan 2020 12:58:27 -0800 Message-ID: To: Ralf Weber Cc: Christian Huitema , ADD Mailing list , John Levine Content-Type: multipart/alternative; boundary="000000000000433d26059b2e758c" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 20:58:44 -0000 --000000000000433d26059b2e758c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 1:33 AM Ralf Weber wrote: > Also open resolvers are often operated as or on honeypots and thus it > somehow is expected that this data shows up at security companies that > might replay/look at it. > > This fact that the ISP might not sell the data is even mentioned at the > bottom of the report, but of course not in the headline as this wouldn=E2= =80=99t > generate clicks. > Sure, but the fact that data "shows up" at other companies (whether they are doing security, advertising, or something else) is what efforts like the TRR program are trying to prevent. Whether they actually sold the data is of course not obvious from the experiment. thanks, Rob --000000000000433d26059b2e758c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 2, 2020 at 1:33 AM Ralf Weber= <dns@fl1ger.de> wrote:
Also open resolvers are often operated as or on honeypots and thus it
somehow is expected that this data shows up at security companies that
might replay/look at it.

This fact that the ISP might not sell the data is even mentioned at the
bottom of the report, but of course not in the headline as this wouldn=E2= =80=99t
generate clicks.

Sure, but the fact tha= t data "shows up" at other companies (whether they are doing secu= rity, advertising, or something else) is what efforts like the TRR program = are trying to prevent.

Whether they actually sold = the data is of course not obvious from the experiment.

=
thanks,
Rob

--000000000000433d26059b2e758c-- From nobody Thu Jan 2 13:17:29 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7B120164 for ; Thu, 2 Jan 2020 13:17:27 -0800 (PST) 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 1vIZ_gq5rfj2 for ; Thu, 2 Jan 2020 13:17:24 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 6B10712004D for ; Thu, 2 Jan 2020 13:17:24 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id y3so10156649uae.3 for ; Thu, 02 Jan 2020 13:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qRyf2oyDmHdtSKKyFbgAoUE4Wl7/wWjupocKwkdBEC4=; b=G302OKCHHJQygOwYXe4RgXfjm9QA3AVoOaVmfEZ7HXi76sbeSvQiidnPmjXSrRJUwU +cMhe9cpIxK9K9VB9R+l4x6ED2SjWEwzY2LqEE9P/JMP7EP9F00TudX1kBRB+0ro2WWg v3c413MI0X/D0S8DMiKzrEPR0SEH2380HYUJ2Af9AzLaF2WbvDc/ZHkGPZ5ctH1KEGEA +BpR8S/T1jDmEGZuhUxP1t9bGIuXSv5Dlmznn4uNFU3SqDgu7M08Pn8uyKhYOuDLic2e Bp9yJOfwiRsPZHdbDKbx7i7q1CnsPBKefStU0sjJrxYHBVTRNISlNa6G/SL+gGVyUpOQ bz/Q== 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=qRyf2oyDmHdtSKKyFbgAoUE4Wl7/wWjupocKwkdBEC4=; b=FwW+XA2MH85bDVdQ2g/k9GkaAGdpcpCYRbPvSZ/vJQc8nTqdCcdN/DLR1wXZa2Ty4x wmcrvXVgQ/5iimkeKzuFiNgsQSlpmSrMZr7LbyRU3af79xgFWGk7CAvUJylS3TXju+VG BU94LHoTa4uON77dqluKRsLp1/DejlGPBMIbwA4mz/A86yQTzkFn9VgeO54flnEYCE4O tX9tyBWcb/CrBGGT0CW1UFODmNqkR8uRGkUD1fFVfEfExhB4VQ46zfnSMAcezrVBAcPr VMkKvDm9gPUuYPhNQAQQXSvkWvYwrKD+Oxgo8L+xfQ3crEhcpRjsFVQSTHYz47MJTSDG 3u2g== X-Gm-Message-State: APjAAAUJVm6/C7ANgQhFY5Sm45PDLqe2jiWEll0g8GXTYZ37jD1k53Xc WBQqpEgUib/rQhBVouM/1wykceTsnfEarnYKHcA1TA== X-Google-Smtp-Source: APXvYqyRvwyJJIqQhOnrWDcdoNhBzEdtQNjO5pjdADhbrNiaOmDpKvVTQ/JxE0CTT7OzncXhZQ2nk5WxlVm973U3BX0= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr41324421uaq.114.1577999843422; Thu, 02 Jan 2020 13:17:23 -0800 (PST) MIME-Version: 1.0 References: <573C729A-F27E-4230-BB0B-94533B6CBC5B@fugue.com> In-Reply-To: <573C729A-F27E-4230-BB0B-94533B6CBC5B@fugue.com> From: Brian Dickson Date: Thu, 2 Jan 2020 13:17:12 -0800 Message-ID: To: Ted Lemon Cc: Ralf Weber , Michael Richardson , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000001f7691059b2eb8ea" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 21:17:28 -0000 --0000000000001f7691059b2eb8ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 6:11 AM Ted Lemon wrote: > On Jan 2, 2020, at 5:00 AM, Ralf Weber wrote: > > Can you define trust relationship / authenticating configuration data. > Depending on how you define that the solution is either obvious or > impossible. As an ops guy and non native english speaker I often struggle > with abstractions, so let me give you an concrete example you can hopeful= ly > give an answer on: > > Good questions, thanks. > > > - A router sends a client an PvD RA as defined in > (draft-bruneau-intarea-provisioning-domains - > https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ > ) with FQDN content of pvd.myisp.net. > > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can > DNSSEC validate the domain and the HTTP certificate > > - In the JSON blob retrieved contains the following keys (see > draft-pauly-dprive-adaptive-dns-privacy - > https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/= ?include_text=3D1 > ): > > dohuri: https://doh.myisp.net/dns-query > > requireDNSFiltering: True > > dnsFilteredZones: =E2=80=9C.=E2=80=9D > > I can again DNSSEC validate the domain and the HTTP certificate using > they key stores available with my system. > > > > Is that authenticated? Is there a trust relationship? > > No. You have no more reason to trust that than you do any other random > HTTPS-authenticated web site that you might try to access. When you go = to > https://www.badguy.com, you know that it=E2=80=99s really www.badguy.com = because > the TLS cert validates, and maybe the DNSSEC validated, but you /don=E2= =80=99t/ > have any reason to trust answers you get from that site. > > That=E2=80=99s why I say there=E2=80=99s no reason to go through any extr= a bother. In > order to have a trust relationship, I need to have configured a list of > sites I trust as DNS resolvers. This is independent of the RA I receive, > or the DHCP message I receive. > > Then when I get an RA or a DHCP message asserting the availability of a > DNS resolver, if I have a trust relationship with that resolver, and I ca= n > validate the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted r= esolver.=E2=80=9D > Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted resolver.=E2=80=9D It=E2= =80=99s the pre-established trust > relationship that makes it trusted, not some assertion I get from the > network about it being trustworthy. > > E.g., suppose I trust the SLA from my ISP. I believe that my ISP will > not snoop on my DNS data, and I want to use their resolver. If their > resolver is using DoH or DoT, then I can list the domain name(s) of their > resolver in my list of trusted resolvers. When I am offered one of thes= e > resolvers, I can validate that I=E2=80=99m actually communicating with it= , by > validating the TLS cert, and then I can trust it, because of that > pre-established trust relationship, not because of any assertion the > network made about its trustworthiness. > > Absent some kind of out-of-band trust establishment process like this, > there can=E2=80=99t be a trust relationship with a resolver. > "If there were any sense to the English language, trust would be a four-letter word." - Risky Business quote. One of the problems we are having in this thread, is the terminology, which I'd like to suggest a couple of substitutes for clarity. "Trust" can have several meanings, which is unfortunate in that the inherent ambiguity causes unclear meaning. Perhaps two distinct terms or phrases would be appropriate - one for what DNSSEC provides (data integrity protection), and one for privacy. Maybe we could just use DNSSEC and privacy? I'd like to start with Ted's last statement, and break it into two related components, which are actually both relevant using both meanings of "trust"= . - Absent some kind of out-of-band DNSSEC establishment process, there can't be a DNSSEC relationship with a resolver (I'd actually prefer to use "server" here, since a client is UNABLE to distinguish a resolver from a forwarder.) - Absent some kind of out-of-band privacy establishment process, there can't be be a privacy relationship with a resolver. (Same concerns on server rather than resolver.) The assumption that may be being made is that the only way to have a DNSSEC relationship with a resolver, is when two conditions are true: - The resolver has a globally unique, resolvable name with a chain of (DNSSEC) trust from the DNS Root Trust Anchor - The name of the resolver is known (or discoverable), and the URI for the service in question is also well-known These generally require some OOB method of discovery/publication/usage. The relevance of the following statement is unclear, but it should be noted: there is basically no way to validate the claim of a given network, of the network's association with the resolver (e.g. whether they are part of the same ISP, etc.) There is another way by which a DNSSEC relationship to a resolver can be established, which is very much non-obvious: the OOB publication of a specific DNSSEC Trust Anchor, for a zone which publishes some server-related information. For example, a DNSKEY associates a name with a public key for a named zone. The contents of that zone can be signed with DNSSEC, and those signatures validated with the DNSKEY. The degree of trust in the DNSSEC status is dependent on the manner of the OOB publication. However, revocation of such trust is trivial (unpublish the zone or roll the key) and provides POP (proof of possession of the private key). The information in a signed zone can be used for bootstrapping any number of related DNS mechanisms (e.g. TLSA records), or even unrelated mechanisms for bootstrapping other associations (lots of possibilities, such as URIs for network support, URIs for web pages that have QR codes for whatever other stuff you want to publish). The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and the real value is being able to use names which have only local significance (e.g. under the local-use ISO namespaces such as "zz"). The bootstrap method for upgrading from DHCP-provided resolver IP could be as simple as connecting on port 53 and asking for a global well-known name, which returns the FQDN of the server (even if that FQDN is locally scoped under "zz"). If a match is found in the set of Trust Anchors, look things up in that zone and validate with the corresponding TA (or the Root TA if the FQDN is global.) Bootstrap to having a DNSSEC trust relationship is then complete. What data is published in a signed zone of this sort is entirely open to standardization, for any number of use cases. Examples could include: - Methods of providing ways of authenticating Access Points (since the SSID is not trustworthy in general, and the normal authentication of public SSIDs is "none" or "client to SSID" rather than the other way around). - URIs for HTTPS connections for arbitrary uses, e.g. including obtaining short-term guest credentials to use on WiFi - URIs for SSL VPNs (much better than just encrypting DNS) - any well-known prefix-based services (_SOMETHING._TCP) - CNAMEs, DNAMEs to FQDN-based services - Anything anyone wants to standardize for bootstrapping from locally scoped network connections Brian --0000000000001f7691059b2eb8ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 6:11 AM Ted Le= mon <mellon@fugue.com> wrote:=
On Jan 2, 2020,= at 5:00 AM, Ralf Weber <dns@fl1ger.de> wrote:
> Can you define trust relationship / authenticating configuration data.= Depending on how you define that the solution is either obvious or impossi= ble. As an ops guy and non native english speaker I often struggle with abs= tractions, so let me give you an concrete example you can hopefully give an= answer on:

Good questions, thanks.

> - A router sends a client an PvD RA as defined in (draft-bruneau-intar= ea-provisioning-domains - h= ttps://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ ) with FQDN content of pvd.myisp.net.
> - My system retrieves https://pvd.myisp.net/.well-known/pv= d and can DNSSEC validate the domain and the HTTP certificate
> - In the JSON blob retrieved contains the following keys (see draft-pa= uly-dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-pauly-dprive= -adaptive-dns-privacy/?include_text=3D1 ):
>=C2=A0 =C2=A0 dohuri: https://doh.myisp.net/dns-query
>=C2=A0 =C2=A0 requireDNSFiltering: True
>=C2=A0 =C2=A0 dnsFilteredZones: =E2=80=9C.=E2=80=9D
> I can again DNSSEC validate the domain and the HTTP certificate using = they key stores available with my system.
>
> Is that authenticated? Is there a trust relationship?

No.=C2=A0 =C2=A0You have no more reason to trust that than you do any other= random HTTPS-authenticated web site that you might try to access.=C2=A0 = =C2=A0When you go to https://www.badguy.com, you know that it=E2=80=99s re= ally www.badguy.com because the TLS cert validates, and maybe the DNSSEC va= lidated, but you /don=E2=80=99t/ have any reason to trust answers you get f= rom that site.

That=E2=80=99s why I say there=E2=80=99s no reason to go through any extra = bother.=C2=A0 =C2=A0In order to have a trust relationship, I need to have c= onfigured a list of sites I trust as DNS resolvers.=C2=A0 This is independe= nt of the RA I receive, or the DHCP message I receive.

Then when I get an RA or a DHCP message asserting the availability of a DNS= resolver, if I have a trust relationship with that resolver, and I can val= idate the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted resolv= er.=E2=80=9D=C2=A0 =C2=A0Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted reso= lver.=E2=80=9D=C2=A0 =C2=A0It=E2=80=99s the pre-established trust relations= hip that makes it trusted, not some assertion I get from the network about = it being trustworthy.

E.g., suppose I trust the SLA from my ISP.=C2=A0 =C2=A0I believe that my IS= P will not snoop on my DNS data, and I want to use their resolver.=C2=A0 = =C2=A0If their resolver is using DoH or DoT, then I can list the domain nam= e(s) of their resolver in my list of trusted resolvers.=C2=A0 =C2=A0When I = am offered one of these resolvers, I can validate that I=E2=80=99m actually= communicating with it, by validating the TLS cert, and then I can trust it= , because of that pre-established trust relationship, not because of any as= sertion the network made about its trustworthiness.

Absent some kind of out-of-band trust establishment process like this, ther= e can=E2=80=99t be a trust relationship with a resolver.

"If there were any sense to the English language, tr= ust would be a four-letter word." - Risky Business quote.
One of the problems we are having in this thread, is the termi= nology, which I'd like to suggest a couple of substitutes for clarity.<= /div>
"Trust" can have several meanings, which is unfortunate= in that the inherent ambiguity causes unclear meaning.

Perhaps two distinct terms or phrases would be appropriate - one for = what DNSSEC provides (data integrity protection), and one for privacy.=C2= =A0
Maybe we could just use DNSSEC and privacy?

I'd like to start with Ted's last statement, and break it i= nto two related components, which are actually both relevant using both mea= nings of "trust".
- Absent some kind of out-of-band DNS= SEC establishment process, there can't be a DNSSEC relationship with a = resolver=C2=A0
=C2=A0 =C2=A0(I'd actually prefer to use "= ;server" here, since a client is UNABLE to distinguish a resolver from= a forwarder.)
- Absent some kind of out-of-band privacy establis= hment process, there can't be be a privacy relationship with a resolver= . (Same concerns on server rather than resolver.)

= The assumption that may be being made is that the only way to have a DNSSEC= relationship with a resolver, is when two conditions are true:
-= The resolver has a globally unique, resolvable name with a chain of (DNSSE= C) trust from the DNS Root Trust Anchor
- The name of the resolve= r is known (or discoverable), and the URI for the service in question is al= so well-known
These generally require some OOB method of discover= y/publication/usage.
The relevance of the following statement is = unclear, but it should be noted: there is basically no way to validate the = claim of a given network, of the network's association with the resolve= r (e.g. whether they are part of the same ISP, etc.)

There is another way by which a DNSSEC relationship to a resolver can be= established, which is very much non-obvious: the OOB publication of a spec= ific DNSSEC Trust Anchor, for a zone which publishes some server-related in= formation.
For example, a DNSKEY associates a name with a public = key for a named zone. The contents of that zone can be signed with DNSSEC, = and those signatures validated with the DNSKEY.=C2=A0
The degree = of trust in the DNSSEC status is dependent on the manner of the OOB publica= tion. However, revocation of such trust is trivial (unpublish the zone or r= oll the key) and provides POP (proof of possession of the private key).

The information in a signed zone can be used for boot= strapping any number of related DNS mechanisms (e.g. TLSA records), or even= unrelated mechanisms for bootstrapping other associations (lots of possibi= lities, such as URIs for network support, URIs for web pages that have QR c= odes for whatever other stuff you want to publish).

The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and t= he real value is being able to use names which have only local significance= (e.g. under the local-use ISO namespaces such as "zz").

The bootstrap method for upgrading from DHCP-provided reso= lver IP could be as simple as connecting on port 53 and asking for a global= well-known name, which returns the FQDN of the server (even if that FQDN i= s locally scoped under "zz"). If a match is found in the set of T= rust Anchors, look things up in that zone and validate with the correspondi= ng TA (or the Root TA if the FQDN is global.) Bootstrap to having a DNSSEC = trust relationship is then complete.

What data is = published in a signed zone of this sort is entirely open to standardization= , for any number of use cases.

Examples could incl= ude:
- Methods of providing ways of authenticating Access Points = (since the SSID is not trustworthy in general, and the normal authenticatio= n of public SSIDs is "none" or "client to SSID" rather = than the other way around).
- URIs for HTTPS connections for arbi= trary uses, e.g. including obtaining short-term guest credentials to use on= WiFi
- URIs for SSL VPNs (much better than just encrypting DNS)<= /div>
- any well-known prefix-based services (_SOMETHING._TCP)
- CNAMEs, DNAMEs to FQDN-based services
- Anything anyone wants= to standardize for bootstrapping from locally scoped network connections

Brian
=C2=A0
--0000000000001f7691059b2eb8ea-- From nobody Thu Jan 2 13:24:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F78120110 for ; Thu, 2 Jan 2020 13:24:51 -0800 (PST) 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 Z62Gg8vOLGnb for ; Thu, 2 Jan 2020 13:24:49 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 9DC3712004D for ; Thu, 2 Jan 2020 13:24:49 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id 1so14053367uao.1 for ; Thu, 02 Jan 2020 13:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qgTiP4rnlc6iEXav2OMS+j9i5Lxw3PId+KmGWvBu3Yc=; b=dL/2VgArdqMKAX7t91LjW6zGpAb7PNz6euoZPzMdCEd/Ybm5DTgMidsU8Nm8QhRDg+ ErpXQX9opYIdaH104D2JpCrEJT9NBOU3RQrFd0xShUeOIJf3Dxh9P4WkiqeIOrm5VFWg ZDD/2t8uOV+oH+bFZjhmhmQEPYGZJjwAHB/epbetb+x7YC0fEONXpSBvvjIJ8F/Fhgps Dxt4OOs5TsTYMRV/XBuz094237Mk5voQ5I9TAnxU9RRjXmEq5b/btLq5yFvlV/MTMUQt iWkzSkQB3RRuIsu4LvruboVwfqeO/jfjh+8XOpgsJmwz9HH9e4EEZbHwBtCH6jS6s2nl ZSTg== 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=qgTiP4rnlc6iEXav2OMS+j9i5Lxw3PId+KmGWvBu3Yc=; b=s+Z8BXYoaX+RjWDLUGVZflmLeUH2DQbIoO4ybLAPOCjg7GbmEQoudoNeJB8SeynsEU 04U15JLe31fVss4vYDmGRjV6XsRVRNPintKnWzhCC7ahmAiEW19R+ZGCi+LFAeq121cQ MNQVTbjYioyR+Ehzpt9dL+qUIA/ixoXlQxEik/h5TjZeXNR5HZodlor1pMbo11cL3GjA t4vb+rsm+PbBNQnNKIvOs0BapH3AI3jn1XRQEHvpIzBL+D+4aAb+rX2bQvNZgdi1BUyq V+7ApIN81k9pPdy76ShehTEOlinc6CqN756PK49RXSj8UkwFRjTvatnHIouW8DOnryqE TQlQ== X-Gm-Message-State: APjAAAUH3pUtgkoxNSsYquXQwLNjZajVufcx+mUzu8ze0Qhs6FkIm1w0 G7IazEQBw4MF1i6rrtS39ZBYiPmPi0nEiI/BZOE= X-Google-Smtp-Source: APXvYqy+sAObha9D6SXkEEfrtmM9U3ki27rpjIgKZ5BAyueVMJO+4Q+JdxkLtvNNcfsV2iN+XaLegVuF6ypKZAozPgE= X-Received: by 2002:ab0:2505:: with SMTP id j5mr34181436uan.87.1578000288678; Thu, 02 Jan 2020 13:24:48 -0800 (PST) MIME-Version: 1.0 References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> In-Reply-To: From: Brian Dickson Date: Thu, 2 Jan 2020 13:24:37 -0800 Message-ID: To: Rob Sayre Cc: Ralf Weber , John Levine , ADD Mailing list , Christian Huitema Content-Type: multipart/alternative; boundary="000000000000a98a42059b2ed26d" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 21:24:51 -0000 --000000000000a98a42059b2ed26d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 12:58 PM Rob Sayre wrote: > On Thu, Jan 2, 2020 at 1:33 AM Ralf Weber wrote: > >> Also open resolvers are often operated as or on honeypots and thus it >> somehow is expected that this data shows up at security companies that >> might replay/look at it. >> >> This fact that the ISP might not sell the data is even mentioned at the >> bottom of the report, but of course not in the headline as this wouldn= =E2=80=99t >> generate clicks. >> > > Sure, but the fact that data "shows up" at other companies (whether they > are doing security, advertising, or something else) is what efforts like > the TRR program are trying to prevent. > Actually, IMHO, no, this is exactly what TRR programs are *not* trying to prevent, and the fact that these honeypots get adversely affected is the "poster child" of the problem with TRRs being substituted for resolvers in use. Honeypot DNS servers listen on arbitrary ranges of IP addresses, which are either known to not operate "real" resolvers, or are known to operate resolvers used by malware operators (think C&C related servers). Traffic to the real DNS servers on those ranges of IPs, by definition is abnormal, and likely malicious, or at a minimum suspicious. That traffic may be seen as the result of network-level redirection by network operators (including enterprises), and may not necessarily occur as the result of "natural routing" on a destination IP address alone. If you think that TRR programs are trying to prevent that particular traffic, maybe you could explain why you believe that, or what that would actually do for anyone's benefit? Brian --000000000000a98a42059b2ed26d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 12:58 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Thu, Jan 2, 2020 at 1:33 AM Ralf Weber <dns@fl1ger.de> wrote:
Also open resolvers are often operated as or on honeypots and thus it
somehow is expected that this data shows up at security companies that
might replay/look at it.

This fact that the ISP might not sell the data is even mentioned at the
bottom of the report, but of course not in the headline as this wouldn=E2= =80=99t
generate clicks.

Sure, but the fact tha= t data "shows up" at other companies (whether they are doing secu= rity, advertising, or something else) is what efforts like the TRR program = are trying to prevent.

Ac= tually, IMHO, no, this is exactly what TRR programs are *not* trying to pre= vent, and the fact that these honeypots get adversely affected is the "= ;poster child" of the problem with TRRs being substituted for resolver= s in use.

Honeypot DNS servers listen on arbitrary= ranges of IP addresses, which are either known to not operate "real&q= uot; resolvers, or are known to operate resolvers used by malware operators= (think C&C related servers).

Traffic to the r= eal DNS servers on those ranges of IPs, by definition is abnormal, and like= ly malicious, or at a minimum suspicious.

That tra= ffic may be seen as the result of network-level redirection by network oper= ators (including enterprises), and may not necessarily occur as the result = of "natural routing" on a destination IP address alone.

If you think that TRR programs are trying to prevent that p= articular traffic, maybe you could explain why you believe that, or what th= at would actually do for anyone's benefit?

Bri= an
--000000000000a98a42059b2ed26d-- From nobody Thu Jan 2 15:11:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FDE12011F for ; Thu, 2 Jan 2020 15:11:18 -0800 (PST) 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, MIME_QP_LONG_LINE=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=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 tDLDuxdAFnWO for ; Thu, 2 Jan 2020 15:11:14 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 E945E120096 for ; Thu, 2 Jan 2020 15:11:13 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id d5so35763495qto.0 for ; Thu, 02 Jan 2020 15:11:13 -0800 (PST) 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=R5IIrOLECak8fmg9GCB8otQenfLI5/Yr3gA9yFHwwQs=; b=kPLME7iBrTfRz6ztr0xdGbn9dRyrqq2nGChaPwm/RZIOeNBYHC7BkXi9+aMU/1teUR UuYGlE3B0qaj1pZ6Ys1AWfi4S/l4587zvYnyUQvsvZfx/V1s/piBrYp9smESuzbOpdtn Z7fQFKaVJOny2eOtOzKVX4AMRRTXWdL6lCo0N+q+h+qK+ox+6u9UmHs1MWF0PMMwDR8O bJmkuKgHEsfkQp1112heKzi0hWEwGSfcZHVnKS0ov9rH3XlXHgTtk6NPbpn7OxEobgD4 f4gNqJhz0iz3pnm580LyTBTw3USk23c5q5Klqfzq1Q7WBhyzXEQj9StRVOEEJqLjRlqN HYkQ== 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=R5IIrOLECak8fmg9GCB8otQenfLI5/Yr3gA9yFHwwQs=; b=HHdxaS0hzp9kAsO7XiA6RZIVyiZ/nXEoCeYL62pCofi9xmM8QzgbqhlwxkFoTQBtxT /Rx7hd7+Fj5kz6rCepCDM8B5tP1EWf+dcSN6mTK407fJSpTCcG6cWjDQKThm3NmZlCHN xyddSbsKk0uHSmL2vSK9z8chipMuzjnhAgUre/WqPvoMV1h3ZlT3ctaWQ9Z3quMhYPrb HsgcYbnF6DNjGmhQevoKQAeTc20WCZda3wcGtvWXOl1+K+ygdms8esNQxqaF444/BGel 5P4ImSaHNrlz0iftt8Ishq3QH4kank3hxvNbzKlHv4Fg405JKXM35DTYPwfp7eGXkfsj i99A== X-Gm-Message-State: APjAAAWbU9QvRJvBLqNdF11VQr81GMO9WlxliaseXDfTA40fX8m2t7I6 GOs5pT+cTGjGXPIy8z1f0KsIxw== X-Google-Smtp-Source: APXvYqxDZwpsL01Jzm3MF8FYzDIQbTjtfgWDZpqryRSVSpZNDqG26xK0mkOAJfrQvQMym0P0B66UMw== X-Received: by 2002:ac8:7158:: with SMTP id h24mr60969163qtp.63.1578006672944; Thu, 02 Jan 2020 15:11:12 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:10b7:5ce6:69f6:39fb? ([2601:18b:300:36ee:10b7:5ce6:69f6:39fb]) by smtp.gmail.com with ESMTPSA id l6sm17442314qti.10.2020.01.02.15.11.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jan 2020 15:11:11 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-5065DC68-8CD4-4EE5-A1A3-D9310BAB5F3B Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 2 Jan 2020 18:11:10 -0500 Message-Id: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> References: Cc: Ralf Weber , Michael Richardson , ADD Mailing list In-Reply-To: To: Brian Dickson X-Mailer: iPhone Mail (17E202) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 23:11:18 -0000 --Apple-Mail-5065DC68-8CD4-4EE5-A1A3-D9310BAB5F3B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Actually, the meaning of the term =E2=80=9Ctrust=E2=80=9D in computer securi= ty is not at all ambiguous, and your descriptions make things less clear, no= t more.=20 Most of what you say here is just missing the point I made earlier. Trust is= a decision: in order to do what I want, I must trust some thing. How do I e= nforce this? With cryptographic authentication.=20 DNSSEC is a cryptographic authentication mechanism. It does not establish tr= ust. It allows me to authenticate your identity, which I may or may not trus= t. TLS provides a similar capability.=20 Privacy is a thing that I might or might not trust you to provide for me. On= e of many things. Your identity is how I mark you as trusted. Cryptographic authentication is h= ow I validate that you actually are who you claim to be: that your identity i= s the identity I have marked as trusted. The way you have attempted to explain this is much more complicated, and doe= s not make things clearer. See if you can talk about this in terms of trust= ed services, trusted identity and authentication of identity. It will be a l= ot easier to understand.=20 > On Jan 2, 2020, at 16:17, Brian Dickson wr= ote: >=20 > =EF=BB=BF >=20 >=20 >> On Thu, Jan 2, 2020 at 6:11 AM Ted Lemon wrote: >> On Jan 2, 2020, at 5:00 AM, Ralf Weber wrote: >> > Can you define trust relationship / authenticating configuration data. D= epending on how you define that the solution is either obvious or impossible= . As an ops guy and non native english speaker I often struggle with abstrac= tions, so let me give you an concrete example you can hopefully give an answ= er on: >>=20 >> Good questions, thanks. >>=20 >> > - A router sends a client an PvD RA as defined in (draft-bruneau-intare= a-provisioning-domains - https://datatracker.ietf.org/doc/draft-ietf-intarea= -provisioning-domains/ ) with FQDN content of pvd.myisp.net. >> > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can DNS= SEC validate the domain and the HTTP certificate >> > - In the JSON blob retrieved contains the following keys (see draft-pau= ly-dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-paul= y-dprive-adaptive-dns-privacy/?include_text=3D1 ): >> > dohuri: https://doh.myisp.net/dns-query >> > requireDNSFiltering: True >> > dnsFilteredZones: =E2=80=9C.=E2=80=9D >> > I can again DNSSEC validate the domain and the HTTP certificate using t= hey key stores available with my system. >> >=20 >> > Is that authenticated? Is there a trust relationship? >>=20 >> No. You have no more reason to trust that than you do any other random H= TTPS-authenticated web site that you might try to access. When you go to h= ttps://www.badguy.com, you know that it=E2=80=99s really www.badguy.com beca= use the TLS cert validates, and maybe the DNSSEC validated, but you /don=E2=80= =99t/ have any reason to trust answers you get from that site. >>=20 >> That=E2=80=99s why I say there=E2=80=99s no reason to go through any extr= a bother. In order to have a trust relationship, I need to have configured= a list of sites I trust as DNS resolvers. This is independent of the RA I r= eceive, or the DHCP message I receive. >>=20 >> Then when I get an RA or a DHCP message asserting the availability of a D= NS resolver, if I have a trust relationship with that resolver, and I can va= lidate the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted resolv= er.=E2=80=9D Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted resolver.=E2=80= =9D It=E2=80=99s the pre-established trust relationship that makes it trus= ted, not some assertion I get from the network about it being trustworthy. >>=20 >> E.g., suppose I trust the SLA from my ISP. I believe that my ISP will n= ot snoop on my DNS data, and I want to use their resolver. If their resolv= er is using DoH or DoT, then I can list the domain name(s) of their resolver= in my list of trusted resolvers. When I am offered one of these resolvers= , I can validate that I=E2=80=99m actually communicating with it, by validat= ing the TLS cert, and then I can trust it, because of that pre-established t= rust relationship, not because of any assertion the network made about its t= rustworthiness. >>=20 >> Absent some kind of out-of-band trust establishment process like this, th= ere can=E2=80=99t be a trust relationship with a resolver. >=20 > "If there were any sense to the English language, trust would be a four-le= tter word." - Risky Business quote. >=20 > One of the problems we are having in this thread, is the terminology, whic= h I'd like to suggest a couple of substitutes for clarity. > "Trust" can have several meanings, which is unfortunate in that the inhere= nt ambiguity causes unclear meaning. >=20 > Perhaps two distinct terms or phrases would be appropriate - one for what D= NSSEC provides (data integrity protection), and one for privacy.=20 > Maybe we could just use DNSSEC and privacy? >=20 > I'd like to start with Ted's last statement, and break it into two related= components, which are actually both relevant using both meanings of "trust"= . > - Absent some kind of out-of-band DNSSEC establishment process, there can'= t be a DNSSEC relationship with a resolver=20 > (I'd actually prefer to use "server" here, since a client is UNABLE to d= istinguish a resolver from a forwarder.) > - Absent some kind of out-of-band privacy establishment process, there can= 't be be a privacy relationship with a resolver. (Same concerns on server ra= ther than resolver.) >=20 > The assumption that may be being made is that the only way to have a DNSSE= C relationship with a resolver, is when two conditions are true: > - The resolver has a globally unique, resolvable name with a chain of (DNS= SEC) trust from the DNS Root Trust Anchor > - The name of the resolver is known (or discoverable), and the URI for the= service in question is also well-known > These generally require some OOB method of discovery/publication/usage. > The relevance of the following statement is unclear, but it should be note= d: there is basically no way to validate the claim of a given network, of th= e network's association with the resolver (e.g. whether they are part of the= same ISP, etc.) >=20 > There is another way by which a DNSSEC relationship to a resolver can be e= stablished, which is very much non-obvious: the OOB publication of a specifi= c DNSSEC Trust Anchor, for a zone which publishes some server-related inform= ation. > For example, a DNSKEY associates a name with a public key for a named zone= . The contents of that zone can be signed with DNSSEC, and those signatures v= alidated with the DNSKEY.=20 > The degree of trust in the DNSSEC status is dependent on the manner of the= OOB publication. However, revocation of such trust is trivial (unpublish th= e zone or roll the key) and provides POP (proof of possession of the private= key). >=20 > The information in a signed zone can be used for bootstrapping any number o= f related DNS mechanisms (e.g. TLSA records), or even unrelated mechanisms f= or bootstrapping other associations (lots of possibilities, such as URIs for= network support, URIs for web pages that have QR codes for whatever other s= tuff you want to publish). >=20 > The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and th= e real value is being able to use names which have only local significance (= e.g. under the local-use ISO namespaces such as "zz"). >=20 > The bootstrap method for upgrading from DHCP-provided resolver IP could be= as simple as connecting on port 53 and asking for a global well-known name,= which returns the FQDN of the server (even if that FQDN is locally scoped u= nder "zz"). If a match is found in the set of Trust Anchors, look things up i= n that zone and validate with the corresponding TA (or the Root TA if the FQ= DN is global.) Bootstrap to having a DNSSEC trust relationship is then compl= ete. >=20 > What data is published in a signed zone of this sort is entirely open to s= tandardization, for any number of use cases. >=20 > Examples could include: > - Methods of providing ways of authenticating Access Points (since the SSI= D is not trustworthy in general, and the normal authentication of public SSI= Ds is "none" or "client to SSID" rather than the other way around). > - URIs for HTTPS connections for arbitrary uses, e.g. including obtaining s= hort-term guest credentials to use on WiFi > - URIs for SSL VPNs (much better than just encrypting DNS) > - any well-known prefix-based services (_SOMETHING._TCP) > - CNAMEs, DNAMEs to FQDN-based services > - Anything anyone wants to standardize for bootstrapping from locally scop= ed network connections >=20 > Brian > =20 --Apple-Mail-5065DC68-8CD4-4EE5-A1A3-D9310BAB5F3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Actually, the meaning of t= he term =E2=80=9Ctrust=E2=80=9D in computer security is not at all ambiguous= , and your descriptions make things less clear, not more. 

Most of what you say here is just missi= ng the point I made earlier. Trust is a decision: in order to do what I want= , I must trust some thing. How do I enforce this?  With cryptographic a= uthentication. 

DNSSEC= is a cryptographic authentication mechanism. It does not establish trust. I= t allows me to authenticate your identity, which I may or may not trust. TLS= provides a similar capability. 

Privacy is a thing that I might or might not trust you to provide= for me. One of many things.

Your identity is how I mark you as trusted. Cryptographic authentication i= s how I validate that you actually are who you claim to be: that your identi= ty is the identity I have marked as trusted.

The way you have attempted to explain this is much more co= mplicated, and does not make things clearer.  See if you can talk about= this in terms of trusted services, trusted identity and authentication of i= dentity. It will be a lot easier to understand. 
=
On Jan 2, 2020, at 16:17, Brian Dickson <br= ian.peter.dickson@gmail.com> wrote:

=EF=BB=BF
<= br>

On Thu, Jan 2, 2020 at 6:11 AM Ted Lemon <mellon@fugue.com> wrote:
On Jan 2, 2020, at 5:00 AM, Ralf Weber <dns@fl1ger.de> wrote:
> Can you define trust relationship / authenticating configuration data. D= epending on how you define that the solution is either obvious or impossible= . As an ops guy and non native english speaker I often struggle with abstrac= tions, so let me give you an concrete example you can hopefully give an answ= er on:

Good questions, thanks.

> - A router sends a client an PvD RA as defined in (draft-bruneau-intare= a-provisioning-domains - http= s://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ ) w= ith FQDN content of pvd.myisp.net.
> - My system retrieves https://pvd.myisp.net/.well-known/pvd<= /a> and can DNSSEC validate the domain and the HTTP certificate
> - In the JSON blob retrieved contains the following keys (see draft-pau= ly-dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-pauly-dprive-ada= ptive-dns-privacy/?include_text=3D1 ):
>    dohuri: https://doh.myisp.net/dns-query
>    requireDNSFiltering: True
>    dnsFilteredZones: =E2=80=9C.=E2=80=9D
> I can again DNSSEC validate the domain and the HTTP certificate using t= hey key stores available with my system.
>
> Is that authenticated? Is there a trust relationship?

No.   You have no more reason to trust that than you do any other r= andom HTTPS-authenticated web site that you might try to access.   = ;When you go to https://www.badguy.com, you know that it=E2=80=99s really www.bad= guy.com because the TLS cert validates, and maybe the DNSSEC validated, b= ut you /don=E2=80=99t/ have any reason to trust answers you get from that si= te.

That=E2=80=99s why I say there=E2=80=99s no reason to go through any extra b= other.   In order to have a trust relationship, I need to have con= figured a list of sites I trust as DNS resolvers.  This is independent o= f the RA I receive, or the DHCP message I receive.

Then when I get an RA or a DHCP message asserting the availability of a DNS r= esolver, if I have a trust relationship with that resolver, and I can valida= te the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted resolver.=E2= =80=9D   Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted resolver.=E2= =80=9D   It=E2=80=99s the pre-established trust relationship that m= akes it trusted, not some assertion I get from the network about it being tr= ustworthy.

E.g., suppose I trust the SLA from my ISP.   I believe that my ISP= will not snoop on my DNS data, and I want to use their resolver.  &nbs= p;If their resolver is using DoH or DoT, then I can list the domain name(s) o= f their resolver in my list of trusted resolvers.   When I am offe= red one of these resolvers, I can validate that I=E2=80=99m actually communi= cating with it, by validating the TLS cert, and then I can trust it, because= of that pre-established trust relationship, not because of any assertion th= e network made about its trustworthiness.

Absent some kind of out-of-band trust establishment process like this, there= can=E2=80=99t be a trust relationship with a resolver.

"If there were any sense to the English language, trust woul= d be a four-letter word." - Risky Business quote.

O= ne of the problems we are having in this thread, is the terminology, which I= 'd like to suggest a couple of substitutes for clarity.
"Trust" ca= n have several meanings, which is unfortunate in that the inherent ambiguity= causes unclear meaning.

Perhaps two distinct terms= or phrases would be appropriate - one for what DNSSEC provides (data integr= ity protection), and one for privacy. 
Maybe we could just us= e DNSSEC and privacy?

I'd like to start with Ted's l= ast statement, and break it into two related components, which are actually b= oth relevant using both meanings of "trust".
- Absent some kind of= out-of-band DNSSEC establishment process, there can't be a DNSSEC relations= hip with a resolver 
   (I'd actually prefer to use= "server" here, since a client is UNABLE to distinguish a resolver from a fo= rwarder.)
- Absent some kind of out-of-band privacy establishment p= rocess, there can't be be a privacy relationship with a resolver. (Same conc= erns on server rather than resolver.)

The assumptio= n that may be being made is that the only way to have a DNSSEC relationship w= ith a resolver, is when two conditions are true:
- The resolver ha= s a globally unique, resolvable name with a chain of (DNSSEC) trust from the= DNS Root Trust Anchor
- The name of the resolver is known (or dis= coverable), and the URI for the service in question is also well-known
=
These generally require some OOB method of discovery/publication/usage.=
The relevance of the following statement is unclear, but it shoul= d be noted: there is basically no way to validate the claim of a given netwo= rk, of the network's association with the resolver (e.g. whether they are pa= rt of the same ISP, etc.)

There is another way by w= hich a DNSSEC relationship to a resolver can be established, which is very m= uch non-obvious: the OOB publication of a specific DNSSEC Trust Anchor, for a= zone which publishes some server-related information.
For example= , a DNSKEY associates a name with a public key for a named zone. The content= s of that zone can be signed with DNSSEC, and those signatures validated wit= h the DNSKEY. 
The degree of trust in the DNSSEC status is de= pendent on the manner of the OOB publication. However, revocation of such tr= ust is trivial (unpublish the zone or roll the key) and provides POP (proof o= f possession of the private key).

The information i= n a signed zone can be used for bootstrapping any number of related DNS mech= anisms (e.g. TLSA records), or even unrelated mechanisms for bootstrapping o= ther associations (lots of possibilities, such as URIs for network support, U= RIs for web pages that have QR codes for whatever other stuff you want to pu= blish).

The FQDN of such a Trust Anchor, DOES NOT n= eed to be global at all, and the real value is being able to use names which= have only local significance (e.g. under the local-use ISO namespaces such a= s "zz").

The bootstrap method for upgrading from DH= CP-provided resolver IP could be as simple as connecting on port 53 and aski= ng for a global well-known name, which returns the FQDN of the server (even i= f that FQDN is locally scoped under "zz"). If a match is found in the set of= Trust Anchors, look things up in that zone and validate with the correspond= ing TA (or the Root TA if the FQDN is global.) Bootstrap to having a DNSSEC t= rust relationship is then complete.

What data is pu= blished in a signed zone of this sort is entirely open to standardization, f= or any number of use cases.

Examples could include:=
- Methods of providing ways of authenticating Access Points (sinc= e the SSID is not trustworthy in general, and the normal authentication of p= ublic SSIDs is "none" or "client to SSID" rather than the other way around).=
- URIs for HTTPS connections for arbitrary uses, e.g. including o= btaining short-term guest credentials to use on WiFi
- URIs for SS= L VPNs (much better than just encrypting DNS)
- any well-known pre= fix-based services (_SOMETHING._TCP)
- CNAMEs, DNAMEs to FQDN-base= d services
- Anything anyone wants to standardize for bootstrappin= g from locally scoped network connections

Brian
 
= --Apple-Mail-5065DC68-8CD4-4EE5-A1A3-D9310BAB5F3B-- From nobody Thu Jan 2 15:30:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF62120105 for ; Thu, 2 Jan 2020 15:30:34 -0800 (PST) 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 c5q-nHZZvm_t for ; Thu, 2 Jan 2020 15:30:31 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 DC0411200C3 for ; Thu, 2 Jan 2020 15:30:30 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id l6so14097835uap.13 for ; Thu, 02 Jan 2020 15:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ySc8+prDYrGlC2JdCkAPtWS4CI8FXk8nrrRLm6Ax6g=; b=mMP1DLmLZVbNuMf4nB8uFYiXbT5cuyV9OjOqnM55OFWPf5B9nbl8ua887oB5ZUrCzu 9SOFyBU7t4zTHfbhtItM+U90fwW+7346n+Kmjbf2nLJSc6Kj1hSgRS0HvGnWcLFJF+wG ZLimg0aWsE3padLSp//jgh3tMttkCdVV+7k17MHilFGeYV7B0NsudbTTfoPfnGF1GueN g4Z4c/HzlL9t6vHxQPyiVhJxW1EzahYX5w8FVhdyyOjQtMQhlJlXFPiSYT/S5Cljphz+ /vy2oqpj0GWIzQgCr9DViFAZo+Qx8ST8HOrxacjncHGI4mRbSg22duNj/wHn9xz0Nlcg FjtA== 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=0ySc8+prDYrGlC2JdCkAPtWS4CI8FXk8nrrRLm6Ax6g=; b=bJ7ce5BekBZJxjbJmeO3CngCFrU32f6w54EdKdxCjvuMPseZzitHS5taKkyax5dMDc bNRS+oHiREL9HIVB5Qtfw+ob1wT9gdp8siJ1jJB0kT9mKLwuaLCXmCGCdBNsWmQqLZy5 HgZmqSwEs1sBZyAxsvXZmpyVW4NS0MYrqXfTuzPjQA6ecPpGZ/RFu8T80pATnRAd3cD0 01O9jyHyMqbRanNYXxRgXwn4sO5QRkjhoW5qzJ+ZkkKDxMedQy7SnMF1uHbiWmqFd4l1 GjUx4TwZM5wBBt9PLTN8eOrUYk0e71BOBsPWtruPpHzli9BxXnEst6KXr8jj4cVBYHg6 Q4zQ== X-Gm-Message-State: APjAAAXDMWNTIHCTSLNFfFgF2VaK3HtlY0hT9eHMnHZrXNzpyW9x/kQE Q2cvhoayDW+LPImrCwb/FIMU6WjSK00HC/QcilGc6g== X-Google-Smtp-Source: APXvYqxne6PabHf7aZCayz3wH77tEUnbZdGqMrkPehULsYFWRuLoVo5R+C9DaZjYo4QGyPrrFewoQ59FQSl3Yn444mE= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr41639119uaq.114.1578007829841; Thu, 02 Jan 2020 15:30:29 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> In-Reply-To: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> From: Brian Dickson Date: Thu, 2 Jan 2020 15:30:18 -0800 Message-ID: To: Ted Lemon Cc: Ralf Weber , Michael Richardson , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000268ab8059b3094dd" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 23:30:34 -0000 --000000000000268ab8059b3094dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 3:11 PM Ted Lemon wrote: > Actually, the meaning of the term =E2=80=9Ctrust=E2=80=9D in computer sec= urity is not at > all ambiguous, and your descriptions make things less clear, not more. > > Most of what you say here is just missing the point I made earlier. Trust > is a decision: in order to do what I want, I must trust some thing. How d= o > I enforce this? With cryptographic authentication. > > DNSSEC is a cryptographic authentication mechanism. It does not establish > trust. It allows me to authenticate your identity, which I may or may not > trust. TLS provides a similar capability. > Okay, so what I'm referring to is the cryptographic authentication of the data served, not the identity of the server, which is (for the purposes of data integrity of the served data) irrelevant. (Yes, it is also possible to cryptographically authenticate information about a server if that is itself in a signed zone.) What I'm talking about, in this context, is not *what* the server is, but what it *provides*. It does not require TLS, and TLS adds nothing of substance to the the data integrity, with respect to changes to data between the authority server publishing the data, and the client receiving the data. This does, however, largely hinge on whether or not the client does DNSSEC validation. Both aspects (identity and data validation) depend on client DNSSEC validation, unless there is a particular reason for the client to not validate its data. (IMNSHO, that is unwise to do, presuming a reasonably modern general purpose device like laptop, desktop, mobile phone, or tablet. Low-power devices are a different kettle of fish, e.g. IoT devices, and those should really have their own gateways that do validation on their behalf, if the architectural model supports it.) > > Privacy is a thing that I might or might not trust you to provide for me. > One of many things. > > Your identity is how I mark you as trusted. Cryptographic authentication > is how I validate that you actually are who you claim to be: that your > identity is the identity I have marked as trusted. > > The way you have attempted to explain this is much more complicated, and > does not make things clearer. See if you can talk about this in terms of > trusted services, trusted identity and authentication of identity. It wil= l > be a lot easier to understand. > You left out "validated DNS data", which is technically distinct from trusted services, or at least is what I am attempting to distinguish from "trusted privacy on services offered". The client doesn't have to trust the services, if the data can be validated. That's the whole point of DNSSEC, it does not require that the client trust the resolver. If the goal of making DNS secure involved trusting resolvers, that could have been done by having resolvers AXFR the zones, and could have been done like 20 years ago. That wasn't the model, and the design of DNSSEC specifically excludes that trust, precisely because of the underlying trust issues that show up when considering the privacy issues. Trying to solve privacy issues by discarding the entire design and mode of operation of DNSSEC is a major step backwards, IMHO. (Even if particular resolver operators are trustworthy, removing the validation on the client increases the attack surface on signed zones from ~0 to >> ~0, simply by facilitating data modification on the resolver, notwithstanding the theoretical likelihood of that as an attack. Risk =3D cost * probability, and cost is not zero for what is functionally the equivalent to a cache poisoning attack. If validation is done, data modification anywhere other than on the publishing side of DNS is detectable and results only in denial of service, rather than other kinds of results to modified DNS data.) Brian > > On Jan 2, 2020, at 16:17, Brian Dickson > wrote: > > =EF=BB=BF > > > On Thu, Jan 2, 2020 at 6:11 AM Ted Lemon wrote: > >> On Jan 2, 2020, at 5:00 AM, Ralf Weber wrote: >> > Can you define trust relationship / authenticating configuration data. >> Depending on how you define that the solution is either obvious or >> impossible. As an ops guy and non native english speaker I often struggl= e >> with abstractions, so let me give you an concrete example you can hopefu= lly >> give an answer on: >> >> Good questions, thanks. >> >> > - A router sends a client an PvD RA as defined in >> (draft-bruneau-intarea-provisioning-domains - >> https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains= / >> ) with FQDN content of pvd.myisp.net. >> > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can >> DNSSEC validate the domain and the HTTP certificate >> > - In the JSON blob retrieved contains the following keys (see >> draft-pauly-dprive-adaptive-dns-privacy - >> https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy= /?include_text=3D1 >> ): >> > dohuri: https://doh.myisp.net/dns-query >> > requireDNSFiltering: True >> > dnsFilteredZones: =E2=80=9C.=E2=80=9D >> > I can again DNSSEC validate the domain and the HTTP certificate using >> they key stores available with my system. >> > >> > Is that authenticated? Is there a trust relationship? >> >> No. You have no more reason to trust that than you do any other random >> HTTPS-authenticated web site that you might try to access. When you go= to >> https://www.badguy.com, you know that it=E2=80=99s really www.badguy.com= because >> the TLS cert validates, and maybe the DNSSEC validated, but you /don=E2= =80=99t/ >> have any reason to trust answers you get from that site. >> >> That=E2=80=99s why I say there=E2=80=99s no reason to go through any ext= ra bother. In >> order to have a trust relationship, I need to have configured a list of >> sites I trust as DNS resolvers. This is independent of the RA I receive= , >> or the DHCP message I receive. >> >> Then when I get an RA or a DHCP message asserting the availability of a >> DNS resolver, if I have a trust relationship with that resolver, and I c= an >> validate the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted = resolver.=E2=80=9D >> Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted resolver.=E2=80=9D It= =E2=80=99s the pre-established trust >> relationship that makes it trusted, not some assertion I get from the >> network about it being trustworthy. >> >> E.g., suppose I trust the SLA from my ISP. I believe that my ISP will >> not snoop on my DNS data, and I want to use their resolver. If their >> resolver is using DoH or DoT, then I can list the domain name(s) of thei= r >> resolver in my list of trusted resolvers. When I am offered one of the= se >> resolvers, I can validate that I=E2=80=99m actually communicating with i= t, by >> validating the TLS cert, and then I can trust it, because of that >> pre-established trust relationship, not because of any assertion the >> network made about its trustworthiness. >> >> Absent some kind of out-of-band trust establishment process like this, >> there can=E2=80=99t be a trust relationship with a resolver. >> > > "If there were any sense to the English language, trust would be a > four-letter word." - Risky Business quote. > > One of the problems we are having in this thread, is the terminology, > which I'd like to suggest a couple of substitutes for clarity. > "Trust" can have several meanings, which is unfortunate in that the > inherent ambiguity causes unclear meaning. > > Perhaps two distinct terms or phrases would be appropriate - one for what > DNSSEC provides (data integrity protection), and one for privacy. > Maybe we could just use DNSSEC and privacy? > > I'd like to start with Ted's last statement, and break it into two relate= d > components, which are actually both relevant using both meanings of "trus= t". > - Absent some kind of out-of-band DNSSEC establishment process, there > can't be a DNSSEC relationship with a resolver > (I'd actually prefer to use "server" here, since a client is UNABLE to > distinguish a resolver from a forwarder.) > - Absent some kind of out-of-band privacy establishment process, there > can't be be a privacy relationship with a resolver. (Same concerns on > server rather than resolver.) > > The assumption that may be being made is that the only way to have a > DNSSEC relationship with a resolver, is when two conditions are true: > - The resolver has a globally unique, resolvable name with a chain of > (DNSSEC) trust from the DNS Root Trust Anchor > - The name of the resolver is known (or discoverable), and the URI for th= e > service in question is also well-known > These generally require some OOB method of discovery/publication/usage. > The relevance of the following statement is unclear, but it should be > noted: there is basically no way to validate the claim of a given network= , > of the network's association with the resolver (e.g. whether they are par= t > of the same ISP, etc.) > > There is another way by which a DNSSEC relationship to a resolver can be > established, which is very much non-obvious: the OOB publication of a > specific DNSSEC Trust Anchor, for a zone which publishes some > server-related information. > For example, a DNSKEY associates a name with a public key for a named > zone. The contents of that zone can be signed with DNSSEC, and those > signatures validated with the DNSKEY. > The degree of trust in the DNSSEC status is dependent on the manner of th= e > OOB publication. However, revocation of such trust is trivial (unpublish > the zone or roll the key) and provides POP (proof of possession of the > private key). > > The information in a signed zone can be used for bootstrapping any number > of related DNS mechanisms (e.g. TLSA records), or even unrelated mechanis= ms > for bootstrapping other associations (lots of possibilities, such as URIs > for network support, URIs for web pages that have QR codes for whatever > other stuff you want to publish). > > The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and > the real value is being able to use names which have only local > significance (e.g. under the local-use ISO namespaces such as "zz"). > > The bootstrap method for upgrading from DHCP-provided resolver IP could b= e > as simple as connecting on port 53 and asking for a global well-known nam= e, > which returns the FQDN of the server (even if that FQDN is locally scoped > under "zz"). If a match is found in the set of Trust Anchors, look things > up in that zone and validate with the corresponding TA (or the Root TA if > the FQDN is global.) Bootstrap to having a DNSSEC trust relationship is > then complete. > > What data is published in a signed zone of this sort is entirely open to > standardization, for any number of use cases. > > Examples could include: > - Methods of providing ways of authenticating Access Points (since the > SSID is not trustworthy in general, and the normal authentication of publ= ic > SSIDs is "none" or "client to SSID" rather than the other way around). > - URIs for HTTPS connections for arbitrary uses, e.g. including obtaining > short-term guest credentials to use on WiFi > - URIs for SSL VPNs (much better than just encrypting DNS) > - any well-known prefix-based services (_SOMETHING._TCP) > - CNAMEs, DNAMEs to FQDN-based services > - Anything anyone wants to standardize for bootstrapping from locally > scoped network connections > > Brian > > > --000000000000268ab8059b3094dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 3:11 PM Ted Le= mon <mellon@fugue.com> wrote:=
Actually, the meaning of the term =E2=80=9Ctrust=E2=80= =9D in computer security is not at all ambiguous, and your descriptions mak= e things less clear, not more.=C2=A0

Most of what you say here is just missing the point I made earli= er. Trust is a decision: in order to do what I want, I must trust some thin= g. How do I enforce this?=C2=A0 With cryptographic authentication.=C2=A0

DNSSEC is a cryptographic au= thentication mechanism. It does not establish trust. It allows me to authen= ticate your identity, which I may or may not trust. TLS provides a similar = capability.=C2=A0

Okay, so what= I'm referring to is the cryptographic authentication of the data serve= d, not the identity of the server, which is (for the purposes of data integ= rity of the served data) irrelevant.

(Yes, it is a= lso possible to cryptographically authenticate information about a server i= f that is itself in a signed zone.)

What I'm t= alking about, in this context, is not *what* the server is, but what it *pr= ovides*.

It does not require TLS, and TLS adds not= hing of substance to the the data integrity, with respect to changes to dat= a between the authority server publishing the data, and the client receivin= g the data.

This does, however, largely hinge on w= hether or not the client does DNSSEC validation.

B= oth aspects (identity and data validation) depend on client DNSSEC validati= on, unless there is a particular reason for the client to not validate its = data. (IMNSHO, that is unwise to do, presuming a reasonably modern general = purpose device like laptop, desktop, mobile phone, or tablet. Low-power dev= ices are a different kettle of fish, e.g. IoT devices, and those should rea= lly have their own gateways that do validation on their behalf, if the arch= itectural model supports it.)
=C2=A0

Privacy is a thing that I might or might not trust you to pro= vide for me. One of many things.

Your identity is how I mark you as trusted. Cryptographic authenti= cation is how I validate that you actually are who you claim to be: that yo= ur identity is the identity I have marked as trusted.
=C2=A0
The wa= y you have attempted to explain this is much more complicated, and does not= make things clearer.=C2=A0 See if you can talk about this in terms of trus= ted services, trusted identity and authentication of identity. It will be a= lot easier to understand.=C2=A0

You left out "validated DNS data", which is technically distinc= t from trusted services, or at least is what I am attempting to distinguish= from "trusted privacy on services offered".

=
The client doesn't have to trust the services, if the data can be = validated.=C2=A0
That's the whole point of DNSSEC, it does no= t require that the client trust the resolver.
If the goal of maki= ng DNS secure involved trusting resolvers, that could have been done by hav= ing resolvers AXFR the zones, and could have been done like 20 years ago.
That wasn't the model, and the design of DNSSEC specifically e= xcludes that trust, precisely because of the underlying trust issues that s= how up when considering the privacy issues.

Trying= to solve privacy issues by discarding the entire design and mode of operat= ion of DNSSEC is a major step backwards, IMHO.

(Ev= en if particular resolver operators are trustworthy, removing the validatio= n on the client increases the attack surface on signed zones from ~0 to >= ;> ~0, simply by facilitating data modification on the resolver, notwith= standing the theoretical likelihood of that as an attack. Risk =3D cost * p= robability, and cost is not zero for what is functionally the equivalent to= a cache poisoning attack. If validation is done, data modification anywher= e other than on the publishing side of DNS is detectable and results only i= n denial of service, rather than other kinds of results to modified DNS dat= a.)

Brian
=C2=A0

On Jan 2, 2020, at 16:17, Brian Dickson <brian.peter.dic= kson@gmail.com> wrote:

=EF=BB=BF


On T= hu, Jan 2, 2020 at 6:11 AM Ted Lemon <mellon@fugue.com> wrote:
On Jan 2, 2020, at 5:00 AM, Ralf Weber = <dns@fl1ger.de>= ; wrote:
> Can you define trust relationship / authenticating configuration data.= Depending on how you define that the solution is either obvious or impossi= ble. As an ops guy and non native english speaker I often struggle with abs= tractions, so let me give you an concrete example you can hopefully give an= answer on:

Good questions, thanks.

> - A router sends a client an PvD RA as defined in (draft-bruneau-intar= ea-provisioning-domains - h= ttps://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ ) with FQDN content of pvd.myisp.net.
> - My system retrieves https://pvd.myisp.net/.well-known/pv= d and can DNSSEC validate the domain and the HTTP certificate
> - In the JSON blob retrieved contains the following keys (see draft-pa= uly-dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-pauly-dprive= -adaptive-dns-privacy/?include_text=3D1 ):
>=C2=A0 =C2=A0 dohuri: https://doh.myisp.net/dns-query
>=C2=A0 =C2=A0 requireDNSFiltering: True
>=C2=A0 =C2=A0 dnsFilteredZones: =E2=80=9C.=E2=80=9D
> I can again DNSSEC validate the domain and the HTTP certificate using = they key stores available with my system.
>
> Is that authenticated? Is there a trust relationship?

No.=C2=A0 =C2=A0You have no more reason to trust that than you do any other= random HTTPS-authenticated web site that you might try to access.=C2=A0 = =C2=A0When you go to https://www.badguy.com, you know that it=E2=80=99s re= ally www.badguy.com because the TLS cert validates, and maybe the DNSSEC va= lidated, but you /don=E2=80=99t/ have any reason to trust answers you get f= rom that site.

That=E2=80=99s why I say there=E2=80=99s no reason to go through any extra = bother.=C2=A0 =C2=A0In order to have a trust relationship, I need to have c= onfigured a list of sites I trust as DNS resolvers.=C2=A0 This is independe= nt of the RA I receive, or the DHCP message I receive.

Then when I get an RA or a DHCP message asserting the availability of a DNS= resolver, if I have a trust relationship with that resolver, and I can val= idate the cert upon connecting, then it=E2=80=99s a =E2=80=9Ctrusted resolv= er.=E2=80=9D=C2=A0 =C2=A0Otherwise, it=E2=80=99s an =E2=80=9Cuntrusted reso= lver.=E2=80=9D=C2=A0 =C2=A0It=E2=80=99s the pre-established trust relations= hip that makes it trusted, not some assertion I get from the network about = it being trustworthy.

E.g., suppose I trust the SLA from my ISP.=C2=A0 =C2=A0I believe that my IS= P will not snoop on my DNS data, and I want to use their resolver.=C2=A0 = =C2=A0If their resolver is using DoH or DoT, then I can list the domain nam= e(s) of their resolver in my list of trusted resolvers.=C2=A0 =C2=A0When I = am offered one of these resolvers, I can validate that I=E2=80=99m actually= communicating with it, by validating the TLS cert, and then I can trust it= , because of that pre-established trust relationship, not because of any as= sertion the network made about its trustworthiness.

Absent some kind of out-of-band trust establishment process like this, ther= e can=E2=80=99t be a trust relationship with a resolver.

"If there were any sense to the English language, tr= ust would be a four-letter word." - Risky Business quote.
One of the problems we are having in this thread, is the termi= nology, which I'd like to suggest a couple of substitutes for clarity.<= /div>
"Trust" can have several meanings, which is unfortunate= in that the inherent ambiguity causes unclear meaning.

Perhaps two distinct terms or phrases would be appropriate - one for = what DNSSEC provides (data integrity protection), and one for privacy.=C2= =A0
Maybe we could just use DNSSEC and privacy?

I'd like to start with Ted's last statement, and break it i= nto two related components, which are actually both relevant using both mea= nings of "trust".
- Absent some kind of out-of-band DNS= SEC establishment process, there can't be a DNSSEC relationship with a = resolver=C2=A0
=C2=A0 =C2=A0(I'd actually prefer to use "= ;server" here, since a client is UNABLE to distinguish a resolver from= a forwarder.)
- Absent some kind of out-of-band privacy establis= hment process, there can't be be a privacy relationship with a resolver= . (Same concerns on server rather than resolver.)

= The assumption that may be being made is that the only way to have a DNSSEC= relationship with a resolver, is when two conditions are true:
-= The resolver has a globally unique, resolvable name with a chain of (DNSSE= C) trust from the DNS Root Trust Anchor
- The name of the resolve= r is known (or discoverable), and the URI for the service in question is al= so well-known
These generally require some OOB method of discover= y/publication/usage.
The relevance of the following statement is = unclear, but it should be noted: there is basically no way to validate the = claim of a given network, of the network's association with the resolve= r (e.g. whether they are part of the same ISP, etc.)

There is another way by which a DNSSEC relationship to a resolver can be= established, which is very much non-obvious: the OOB publication of a spec= ific DNSSEC Trust Anchor, for a zone which publishes some server-related in= formation.
For example, a DNSKEY associates a name with a public = key for a named zone. The contents of that zone can be signed with DNSSEC, = and those signatures validated with the DNSKEY.=C2=A0
The degree = of trust in the DNSSEC status is dependent on the manner of the OOB publica= tion. However, revocation of such trust is trivial (unpublish the zone or r= oll the key) and provides POP (proof of possession of the private key).

The information in a signed zone can be used for boot= strapping any number of related DNS mechanisms (e.g. TLSA records), or even= unrelated mechanisms for bootstrapping other associations (lots of possibi= lities, such as URIs for network support, URIs for web pages that have QR c= odes for whatever other stuff you want to publish).

The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and t= he real value is being able to use names which have only local significance= (e.g. under the local-use ISO namespaces such as "zz").

The bootstrap method for upgrading from DHCP-provided reso= lver IP could be as simple as connecting on port 53 and asking for a global= well-known name, which returns the FQDN of the server (even if that FQDN i= s locally scoped under "zz"). If a match is found in the set of T= rust Anchors, look things up in that zone and validate with the correspondi= ng TA (or the Root TA if the FQDN is global.) Bootstrap to having a DNSSEC = trust relationship is then complete.

What data is = published in a signed zone of this sort is entirely open to standardization= , for any number of use cases.

Examples could incl= ude:
- Methods of providing ways of authenticating Access Points = (since the SSID is not trustworthy in general, and the normal authenticatio= n of public SSIDs is "none" or "client to SSID" rather = than the other way around).
- URIs for HTTPS connections for arbi= trary uses, e.g. including obtaining short-term guest credentials to use on= WiFi
- URIs for SSL VPNs (much better than just encrypting DNS)<= /div>
- any well-known prefix-based services (_SOMETHING._TCP)
- CNAMEs, DNAMEs to FQDN-based services
- Anything anyone wants= to standardize for bootstrapping from locally scoped network connections

Brian
=C2=A0
--000000000000268ab8059b3094dd-- From nobody Thu Jan 2 15:38:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EE7120169 for ; Thu, 2 Jan 2020 15:38:26 -0800 (PST) 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 ndzuucuDEiop for ; Thu, 2 Jan 2020 15:38:25 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10CB0120105 for ; Thu, 2 Jan 2020 15:38:24 -0800 (PST) Received: from [172.16.46.86] (unknown [113.160.150.145]) (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 E35432421173; Thu, 2 Jan 2020 23:38:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Thu, 2 Jan 2020 23:38:16 +0000 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> To: Brian Dickson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 23:38:27 -0000 The debate about trust terminology/definitions is fascinating. It's very = likely to be a topic that the new WG-to-be could eventually discuss. But = it doesn't belong on this thread. Could we please branch this off = somewhere else so this thread can focus on the charter proposals? = Thanks. From nobody Thu Jan 2 15:47:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846CA120105 for ; Thu, 2 Jan 2020 15:47:00 -0800 (PST) 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 mySq4fKZP1iu for ; Thu, 2 Jan 2020 15:46:58 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 BC5641200E9 for ; Thu, 2 Jan 2020 15:46:58 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id y23so14144275ual.2 for ; Thu, 02 Jan 2020 15:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ThGGainUlph5lxiSwwgq8ITTWh6w/Ionl6WcUvoQjE=; b=ovXKtqszH0ie+XQCtAcRwemoMTvcCn36MsjgrS9nM3QQH40VlIfhVi6YGoV3wIM6gS HIDpD+tnVoFHVfrw7KS1m2vLt7FnDv5ZnwtRhewowyVm838v049/XQo70aDg+tSI80PR ya7vztEFGsGr0wfz4KYJYqjIvjPRUnfeWAns1tFvPW1NzklJ9rsX6EtuVCvMoXJFfKul FkFogeBjuA5pG74d02WNfQOhNp1Gf4DjuKkCOh1u17Cl+dCJSELoTmZu6O8x/yloYYJ1 MfvFBAvQ6zoZLOu/WiGfA+aLDYWVJ0wQjbXUOCY5Yziug5/4/nexogzDhyn9LwW7Pse2 G6Jg== 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=6ThGGainUlph5lxiSwwgq8ITTWh6w/Ionl6WcUvoQjE=; b=IjWtW0zk5uUF26Mus26NuSL9WlcEGlazDGXTXrm5CwoA239couMPIzkUgIqikvva3r sOMdxHtUD6ivlQEp/TqI8Hbld70PBpknXg0fGbCYJY4d2RAJh63XQBLn/mpOxV5GGOP+ tgIXHLR+Ooz+owhwt4GHsSqnWNhGKWyNWHv3XcWzS8B0nSQcpNycij3zxyw3CcBFZp8U Gc/A0RXU4TtvhUUzWJQ4z3zjGwrQwNLt05mkaT+qzfJjxKFifjdnUmijQJucSFD+jom1 n0fbBtFlsSFObjjgjLvqRJt0pofnCPecVMNSGh8ynMdc+1ls2GyaXrn/6p2Va14CIAVs DjmA== X-Gm-Message-State: APjAAAX3Aw2lt82/g0kEtT5dfCvV0uSHpImH4B0Lh0oYBWnARHCfVCHa SpF4EqN3DKt9GyooOJzlrStXzblLm/sdi5H5WB+KO55q X-Google-Smtp-Source: APXvYqySe76oV/ua04eZyMUDnABhLgs1oNrDAsXGZoiek166ZbKnZW22iMtzdNgU1Ve0iJ7u7gVxcKH4FxQlufw8ov4= X-Received: by 2002:a9f:24c1:: with SMTP id 59mr46368402uar.75.1578008817876; Thu, 02 Jan 2020 15:46:57 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> In-Reply-To: <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> From: Brian Dickson Date: Thu, 2 Jan 2020 15:46:46 -0800 Message-ID: To: Jim Reid Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000000ac420059b30cf3d" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 23:47:00 -0000 --0000000000000ac420059b30cf3d Content-Type: text/plain; charset="UTF-8" On Thu, Jan 2, 2020 at 3:38 PM Jim Reid wrote: > The debate about trust terminology/definitions is fascinating. It's very > likely to be a topic that the new WG-to-be could eventually discuss. But it > doesn't belong on this thread. Could we please branch this off somewhere > else so this thread can focus on the charter proposals? Thanks. > Certainly. But, I really want to emphasize, that terminology was a preface to the the meat of my original message, which was that the issues EKR raised, can be addressed, and should be in-scope for the charter proposals. It's the portion of text that begins with "I'd like to start with Ted's last statement"... I'd encourage anyone interested in the charter discussion to take a look at that. This is about having real work to do, which solves the underlying problems related to bootstrapping resolver discovery and the ability to securely obtain metadata in-band (e.g. whatever is relevant to clients) is both useful and relevant, IMHO. Brian --0000000000000ac420059b30cf3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 3:38 PM Jim Re= id <jim@rfc1035.com> wrote:
The debate about t= rust terminology/definitions is fascinating. It's very likely to be a t= opic that the new WG-to-be could eventually discuss. But it doesn't bel= ong on this thread. Could we please branch this off somewhere else so this = thread can focus on the charter proposals? Thanks.
Certainly.

But, I really want to empha= size, that terminology was a preface to the the meat of my original message= , which was that the issues EKR raised, can be addressed, and should be in-= scope for the charter proposals.

It's the port= ion of text that begins with "I'd like to start with Ted's las= t statement"...

I'd encourage anyone inte= rested in the charter discussion to take a look at that.

This is about having real work to do, which solves the underlying pr= oblems related to bootstrapping resolver discovery and the ability to secur= ely obtain metadata in-band (e.g. whatever is relevant to clients) is both = useful and relevant, IMHO.

Brian
--0000000000000ac420059b30cf3d-- From nobody Thu Jan 2 15:56:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898A120147 for ; Thu, 2 Jan 2020 15:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V0zuiWscu_V for ; Thu, 2 Jan 2020 15:56:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BF11200C3 for ; Thu, 2 Jan 2020 15:56:19 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 002NuCxh024136 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Jan 2020 17:56:13 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578009374; bh=fAu/ukBOrHu99JJYAi6GKQeXGFmGyP275Tm2dFe0ZRQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eNp/lUYklojRRh7suPtBX4RqvFap4lXUOlVEzwPm9Ds3qaYtCg8CRVocBLqFglJ5P 0rL2vbhRxvcFkb1B5+txlZ3QHz0JCX6t58S7lmvLRl0+dsv0M6a9hkfaWMvPZiaJZ0 WXsZFZndjY/UG+EqsbhOVwfRyRd6OJam5Y3Eczbw= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Jim Reid , Brian Dickson Cc: ADD Mailing list References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> From: Adam Roach Message-ID: <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> Date: Thu, 2 Jan 2020 17:56:07 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> Content-Type: multipart/alternative; boundary="------------0BF349FE7A9DFE93E21F679B" Content-Language: en-US Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 02 Jan 2020 23:56:21 -0000 This is a multi-part message in MIME format. --------------0BF349FE7A9DFE93E21F679B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as an individual] On 1/2/20 5:38 PM, Jim Reid wrote: > The debate about trust terminology/definitions is fascinating. It's very likely to be a topic that the new WG-to-be could eventually discuss. But it doesn't belong on this thread. Could we please branch this off somewhere else so this thread can focus on the charter proposals? Thanks. > Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other: 1. Do I trust the question I ask to be confidential? [1] 2. Do I trust the answer I get to be accurate? Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter. /a ____ [1] Yes, I recognize that "confidential" raises the question "from whom," and that the answer to that is the real underlying tension in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context. [2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake. [3] https://letsencrypt.org/stats/#percent-pageloads --------------0BF349FE7A9DFE93E21F679B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
[as an individual]

On 1/2/20 5:38 PM, Jim Reid wrote:
The debate about trust terminology/definitions is fascinating. It's very likely to be a topic that the new WG-to-be could eventually discuss. But it doesn't belong on this thread. Could we please branch this off somewhere else so this thread can focus on the charter proposals? Thanks.


Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.


/a

____
[1] Yes, I recognize that "confidential" raises the question "from whom," and that the answer to that is the real underlying tension in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

--------------0BF349FE7A9DFE93E21F679B-- From nobody Thu Jan 2 16:54:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080241200C3 for ; Thu, 2 Jan 2020 16:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 n9tCSUqFLfqb for ; Thu, 2 Jan 2020 16:54:17 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 517DD12006B for ; Thu, 2 Jan 2020 16:54:17 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id w127so32660589qkb.11 for ; Thu, 02 Jan 2020 16:54:17 -0800 (PST) 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=4FKQg2NozFdrmIpuQvQksCB9sYAUZ8KQZ0GKdF8Ybs0=; b=vVFtFVHPKCHH+YtFzo5q25v1adEqzlEO5slDq0k+/v3hnEgvlZpS/BEk5aI+sUbQI7 vLSk58QYuW9bdXqjKt3rN/8ajUn+ayCgMgisC9yCVyRvGj+N5EiU4DVO9ciN8myXQuUr FC2Di500EV+qPG8N8fzJvJJO9Y/PjfPgij2f4x+ldLIY+3nKiEKd4EepwqELLjTn8O6t HlPcBxVim45mjwdjVMPbbFXExCEWr5Bt301qJnNDwuZt7RWLQ6qTwF3cNhW0L8XjcHMn 1zzXBFom66fe1GLVldR1uG+r00VUoof/dCe8MbV5vdFpeTkNLO+e2ycMpP/nL8Ymeism jmXw== 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=4FKQg2NozFdrmIpuQvQksCB9sYAUZ8KQZ0GKdF8Ybs0=; b=XladxWNLzBI44CArhwsjw1eUtUArywdG5MrkN18BVnoVBhXmn4CHkYKQJbq+XkUtB/ NjH0oEz/gbTUDT6ilQjtrP4nN5YqUif/0/Ni3VoROMPRKQcTpXvEw+AOvOcCOkktwxqu fo58WaS8pwMjqMkV225L3B/YhE6SLObq7Fjbak/W9Z6E2qZlz6ANYrShuWGk5bBSqOhP Qdhl2Kta/zLwazbvYGBxn3R+jNeIEac5xbRVIayD2qJvpDBQgFtW6JGv3Az4+DVNAqmq 4CJQ7SGoMF96eyv57jFsGmNfKgGPdLsP7maR+QJxy8Sfs5QOpGdFSHimFWgPq4vZDUE7 RdvA== X-Gm-Message-State: APjAAAWaQ3vmhzNG+o27rgu88HwMT3pd+lZHP/w31+qrfRZXAFyL4oj6 ZEYVE101rmdxfE0if58Dhq0XpQ== X-Google-Smtp-Source: APXvYqy3xA4ZDk/1Hx4ZEMHK9SPXPDJRVqjMeKiN80DREgX5wmYq/sKXWyhwQbTFjTas1LgGbHhRWg== X-Received: by 2002:a37:e317:: with SMTP id y23mr68959546qki.431.1578012856474; Thu, 02 Jan 2020 16:54:16 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:10b7:5ce6:69f6:39fb? ([2601:18b:300:36ee:10b7:5ce6:69f6:39fb]) by smtp.gmail.com with ESMTPSA id 184sm15639764qke.73.2020.01.02.16.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jan 2020 16:54:15 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C19109D8-D07D-4A3B-98EB-8C2A85281C33 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 2 Jan 2020 19:54:14 -0500 Message-Id: References: <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> Cc: Jim Reid , Brian Dickson , ADD Mailing list In-Reply-To: <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> To: Adam Roach X-Mailer: iPhone Mail (17E202) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 03 Jan 2020 00:54:20 -0000 --Apple-Mail-C19109D8-D07D-4A3B-98EB-8C2A85281C33 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Jan 2, 2020, at 18:56, Adam Roach wrote: > Having read through this thread, I think there is a useful charter-related= distinction to be made here, and I think conflating these two things may be= one reason people are talking past each other: >=20 >=20 > Do I trust the question I ask to be confidential? [1] > Do I trust the answer I get to be accurate? >=20 > Given that the only context apparently under discussion is web browsers, a= nd given that the vast majority of HTTP connections are performed over TLS [= 2] [3], I suspect that #1 is the far more interesting question, and the only= one that really makes sense to focus on in the charter. >=20 Indeed, since #2 is solved by DNSSEC. :)= --Apple-Mail-C19109D8-D07D-4A3B-98EB-8C2A85281C33 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On Jan 2, 2020, at 18:56, Adam Roach <adam@nostrum.com> wrote:

Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.


Indeed, since #2 is solved by DNSSEC. :)
--Apple-Mail-C19109D8-D07D-4A3B-98EB-8C2A85281C33-- From nobody Thu Jan 2 17:11:07 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D82B12011A for ; Thu, 2 Jan 2020 17:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ELqSVK_1vJw2 for ; Thu, 2 Jan 2020 17:11:04 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 BEB1612006F for ; Thu, 2 Jan 2020 17:11:04 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id l14so15658752qvu.12 for ; Thu, 02 Jan 2020 17:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Ud8WHscgSjzba2PkrwnwrSTXr0T7kE1tdQqgPX3zZQ=; b=QNxXOpy159esRRCkbNGD3/IvYE/J2KJAlh9/IHiyvjwB8Aaycj4cEvdiO05U/kPJRB P1NEyqG66TALndTA3sHlDT1+TTzucq/063Y9HCpRl1btbGI1MpPbJfOnh1P5m/fSbl5b XGE2a305hD0xOoh5+5svflRDXwo9hlAS0/1ry92jrOG378F2Nfp7n8CxkT+dXGR3Fbo6 BQxqw5STTuWXJIcKGdl71QIbloic+P+/gAbz90rHGhhskDaoU77nzytpWE1Ap9onCr5z AGqguE9Y8kg3uVWkm+D5WoXt0QnMS+P2w9YVZiyjEvM8+IPuo1tOk0E4ojXPUyIfeVwF v8VA== 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=4Ud8WHscgSjzba2PkrwnwrSTXr0T7kE1tdQqgPX3zZQ=; b=q0ZDkRYC7xXP8zernlVOcJ69cFgGji65fBCY+HNH6FjCkxser8W3HYyycSceqjtnpF UDuGXxGSSVib7w3+CTYUqA7fWrGXi2BOb4jDIFP9SCv4O28B1kzXYqkGzO5S4SQUIcWt UnrUTj79dwvF0sfrcPhRlktVqBXhOD29mxLCWMaA3kDl1wRSyEJPnrb/DVbBnBzRXhDU hxvQCrzcf7Veu0UvLP2oKod/Kq6y0CqUsooxM0/sSpO1Vxf3N4RieEwHnSZpEUhUJCeG Mwg47cw1NJemLz3QR6RhLMEhRRYlg7tMTOcnvF4vTZ84AtiOSIfTrrskwYI4axABdY5g wQYA== X-Gm-Message-State: APjAAAUrPqqFJ+JC1mivDpWXR+zqdKG+qaQEr3A22uowAba6ZaSi5m27 WOJfwyb3CoaU1tFo1ohfNArDRGYC9KIorD8kWBWdfZLY X-Google-Smtp-Source: APXvYqyynrDOeGqH53E7N5TZ77TVm1mEtQtnzZo+JszwTaTsP3gOKK9+IJOO893purOW1PM2vU8XkvpUQy7NBUJlEcE= X-Received: by 2002:ad4:5614:: with SMTP id ca20mr66598915qvb.43.1578013863825; Thu, 02 Jan 2020 17:11:03 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> In-Reply-To: <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> From: Alec Muffett Date: Fri, 3 Jan 2020 01:10:27 +0000 Message-ID: To: Adam Roach Cc: Jim Reid , Brian Dickson , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000cdd4c8059b31fb73" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 03 Jan 2020 01:11:06 -0000 --000000000000cdd4c8059b31fb73 Content-Type: text/plain; charset="UTF-8" On Thu, 2 Jan 2020 at 23:56, Adam Roach wrote: > > 1. Do I trust the question I ask to be confidential? [1] > 2. Do I trust the answer I get to be accurate? > > 3. Do I trust the answer will not be blocked? 4. Do I have a relationship with a specific answer provider, and can I be certain that the response I have received has been provided by them [and not surveilled, tampered with, or blocked by any third party, per nos. 1, 2, & 3]? Funny, people keep forgetting that "security" - privacy, integrity - policy extends past the 7-layer model and into "layer 8" aka "administration". -a -- http://dropsafe.crypticide.com/aboutalecm --000000000000cdd4c8059b31fb73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 2 Jan 2020 at 23:56, Adam Roa= ch <adam@nostrum.c= om> wrote:
  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?
3. Do I trust the answer will not be blocked?

4. Do I have a relationship with a specific answer provider, and ca= n I be certain that the response I have received has been provided by them = [and not surveilled, tampered with, or blocked by any third party, per nos.= 1, 2, & 3]?

Funny, people keep forgetting tha= t "security" - privacy, integrity - policy extends past the 7-lay= er model and into "layer 8" aka "administration".
=

=C2=A0 =C2=A0 -a

--
--000000000000cdd4c8059b31fb73-- From nobody Thu Jan 2 22:44:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7DB120073 for ; Thu, 2 Jan 2020 22:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 4p2UQi4clnSz for ; Thu, 2 Jan 2020 22:44:55 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id A5322120072 for ; Thu, 2 Jan 2020 22:44:55 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 97F435F406D3; Fri, 3 Jan 2020 07:44:54 +0100 (CET) Received: from [172.19.176.181] (p54B8AF9C.dip0.t-ipconnect.de [84.184.175.156]) (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 63C5D5F404CA; Fri, 3 Jan 2020 07:44:52 +0100 (CET) From: "Ralf Weber" To: "Rob Sayre" Cc: "Christian Huitema" , "ADD Mailing list" , "John Levine" Date: Fri, 03 Jan 2020 07:44:51 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> In-Reply-To: References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 06:44:58 -0000 Moin! Changing topics to not derail the thread that started this. On 2 Jan 2020, at 21:58, Rob Sayre wrote: > On Thu, Jan 2, 2020 at 1:33 AM Ralf Weber wrote: >> This fact that the ISP might not sell the data is even mentioned at = >> the >> bottom of the report, but of course not in the headline as this = >> wouldn=E2=80=99t >> generate clicks. >> > > Sure, but the fact that data "shows up" at other companies (whether = > they > are doing security, advertising, or something else) is what efforts = > like > the TRR program are trying to prevent. Well the first TRR Cloudflare is sharing its data with APNIC for = research. And as shown by others switching DNS resolution to a central provider does not actually take away information from the network provicder, but merly adds another party that now also has your data: https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-= in-2019-and-beyond/ > Whether they actually sold the data is of course not obvious from the > experiment. Wether they actually had anything to with the data sharing is not = obvivous. Thus the experiment is moot. So long -Ralf =E2=80=94-- Ralf Weber From nobody Thu Jan 2 23:48:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5778120072 for ; Thu, 2 Jan 2020 23:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 KTTRHJ76vLbM for ; Thu, 2 Jan 2020 23:48:08 -0800 (PST) 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 18A76120019 for ; Thu, 2 Jan 2020 23:48:08 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id z193so40577488iof.1 for ; Thu, 02 Jan 2020 23:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xOaWFJCEJmnKxafPwTfP8988aiBqn2cVEijY2GfO1Go=; b=KFX9Q4YuFGPw1rNI8kUC0NHtwEXylNIxSO60T9rzddxCQYEH+4Dcj8xxoHjtJDkc7h Lj8+2HkIjnFJhgnyOnJIuhmWW+5B9vGQ8BDgO7XnwR5ck0Lw979I+89PQyW0fLKeVIj6 uZ53OSeg99l8WGjNCyBpHwD/d0OW2C00nrMhzFG8ImL2LikyyrEMR+SKjuUih6X1KQlg /QTUikPo6HsJMQ+cTPpAKsZtfZva3Ac7sh89hEnRllE9odOnL6rf47COzYOww3Qc2je/ PoyRihMIaP+O9kup5j78Y4zTh2TUaheTte9+HtKlimDO+pTMaRJ06tW7s2L8CN7xAcHP 01dQ== 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=xOaWFJCEJmnKxafPwTfP8988aiBqn2cVEijY2GfO1Go=; b=mJn6viHzEG7VtW61yhOKajMKTPmo5UhjeMps239ZJ8bRhLv2ElXowRWrsIR2ypQL4k x/B1yPYL0Yr2DPIxkZ9Z//quIVtM+TsREtiMXFRmsEsEojSe7W/SDis4scjJUkqdXasp r2Pegaa7QeaxZxJhLz66ocj0EZmnGq7+UBC0IBfmQvlG7i6i7DByRhUunRQtOkW1Ga/D HKhAMrkeb1aiv+itSQmwZY7XeR3B9bI3CePhI7pLcNSkkPweQYv5/vw8Ao62fll+HBZQ R7HlArqoR/0Hwycael9FglVy8WUlJnt9wg/Xx/L268LPZbzRQqFqhlJYY8xd4EyFwvc2 +aFA== X-Gm-Message-State: APjAAAXIJkKf63bZF8WCK1Vcc6FnAWDR/SoIkIqYTpNay1ERGSXXGIgS myeREl99HbWWK7H7Fc7reCg1qE65q9IEtj0gTDc= X-Google-Smtp-Source: APXvYqwCoxgv0clcweYkcSVjUDcJT6yg7lFfWe+PMwsbdbQFdFhbv+1SGNeH9ceN9n9s01Ee/c5kX/jw9FdwBEe/CmQ= X-Received: by 2002:a02:3ece:: with SMTP id s197mr67007738jas.30.1578037687188; Thu, 02 Jan 2020 23:48:07 -0800 (PST) MIME-Version: 1.0 References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> In-Reply-To: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> From: Rob Sayre Date: Thu, 2 Jan 2020 23:47:55 -0800 Message-ID: To: Ralf Weber Cc: Christian Huitema , ADD Mailing list , John Levine Content-Type: multipart/alternative; boundary="000000000000c98691059b3787fe" Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 07:48:10 -0000 --000000000000c98691059b3787fe Content-Type: text/plain; charset="UTF-8" On Thu, Jan 2, 2020 at 10:44 PM Ralf Weber wrote: > > Well the first TRR Cloudflare is sharing its data with APNIC for > research. > Hi, There are some old references to a deal about 1.1.1.1 research data sharing with APNIC, but that would seem to straightforwardly cross the newer Mozilla TRR terms: "2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser." https://wiki.mozilla.org/Security/DOH-resolver-policy Do you have a reference showing that Mozilla DoH traffic under that TRR policy is being shared with APNIC? > And as shown by others switching DNS resolution to a central provider does not actually take away information from the network provicder, but > merly adds another party that now also has your data: > > https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/ Not sure about "as shown". Concerns about governmental jurisdiction seem fair, but what's stopping a European company from agreeing to a TRR policy? (from anyone they trust, not only Mozilla) The other concerns in that post might be accurate for the moment (e.g., those about SNI), but they don't really make a compelling case to preserve the status quo. It's not clear that it makes sense to continue delegating DNS to the local network by default, especially since we're only talking about the case where the network operator does not control the devices. > > Whether they actually sold the data is of course not obvious from the > > experiment. > Wether they actually had anything to with the data sharing is not > obvivous. > Thus the experiment is moot. > It's fair to say it's not clear how the data got shared, and it's definitely not clear that it was sold. However, the data did get shared, something you termed "expected". thanks, Rob --000000000000c98691059b3787fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 2, 2020 at 10:44 PM Ralf Webe= r <dns@fl1ger.de> wrote:

Well the first TRR Cloudflare is sharing its data with APNIC for
research.

Hi,

= There are some old references to a deal about 1.1.1.1 research data sharing= with APNIC, but that would seem to straightforwardly cross the newer Mozil= la TRR terms:

"2. The resolver must not retai= n, sell, or transfer to any third party (except as may be required by law) = any personal information, IP addresses or other user identifiers, or user q= uery patterns from the DNS queries sent from the Firefox browser."

<= /div>
Do you have a reference showing that Mozilla DoH traffic under th= at TRR policy is being shared with APNIC?

=C2=A0
And as shown by others switching DNS resolution to a central provider=C2=A0=
does not actually take away information from the network provicder, but
merly adds another party that now also has your data:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://blog.powerdns.com/2019/09/25/centralised-doh-is-= bad-for-privacy-in-2019-and-beyond/

Not= sure about "as shown". Concerns about governmental jurisdiction = seem fair, but what's stopping a European company from agreeing to a TR= R policy? (from anyone they trust, not only Mozilla)

The other concerns in that post might be accurate for the moment (e.g., = those about SNI), but they don't really make a compelling case to prese= rve the status quo. It's not clear that it makes sense to continue dele= gating DNS to the local network by default, especially since we're only= talking about the case where the network operator does not control the dev= ices.

=C2=A0
> Whether they actually sold the data is of course not obvious from the<= br> > experiment.
Wether they actually had anything to with the data sharing is not
obvivous.
Thus the experiment is moot.

It's f= air to say it's not clear how the data got shared, and it's definit= ely not clear that it was sold.

However, the data= did get shared, something you termed "expected".

<= /div>
thanks,
Rob

--000000000000c98691059b3787fe-- From nobody Fri Jan 3 01:31:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B0A120180 for ; Fri, 3 Jan 2020 01:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 YgYOIak7T-PQ for ; Fri, 3 Jan 2020 01:31:22 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 202281201DB for ; Fri, 3 Jan 2020 01:31:21 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 5C909E6079; Fri, 3 Jan 2020 10:31:19 +0100 (CET) Date: Fri, 03 Jan 2020 10:31:19 +0100 (CET) Message-Id: <20200103.103119.307223552.sthaug@nethelp.no> To: sayrer@gmail.com Cc: dns@fl1ger.de, johnl@taugh.com, add@ietf.org, huitema@huitema.net From: sthaug@nethelp.no In-Reply-To: References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 09:31:24 -0000 Speaking only for myself here: > Not sure about "as shown". Concerns about governmental jurisdiction seem > fair, but what's stopping a European company from agreeing to a TRR policy? > (from anyone they trust, not only Mozilla) Referring to https://wiki.mozilla.org/Security/DOH-resolver-policy specifically "Blocking & Modification Prohibitions": 1. "should not by default block or filter domains unless specifically required by law" - this covers a number of domains we are required to block by the courts (for copyright reasons). So no problem here. However, we also block "child porn" domains. This is a voluntary agreement and as such is not covered by "required by law". This is done by all large Norwegian providers, see https://en.wikipedia.org/wiki/CIRCAMP#Evaluating_sites_for_CSAADF https://no.wikipedia.org/wiki/Kripos%27_barnepornofilter Since this is not directly "required by law", we (AS 2116) could not agree to the current Mozilla TRR policy. (For those who wonder - why don't we simply drop this filtering: - The minister of justice at the time when this was introduced, Knut Storberget, explicitly threatened to make the filter compulsory if the ISPs didn't sign up on the "voluntary" use. See for instance this article from 2008, in Norwegian: https://www.nrk.no/norge/--ta-ansvar-mot-barneporno_-1.6203962 - Management wants us to keep the filtering - possibly because this makes it look like "we are doing something" regarding child porn. Yes, we have told them multiple times that it is easy to evade such filtering.) Steinar Haug, AS 2116 From nobody Fri Jan 3 01:35:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381A5120227 for ; Fri, 3 Jan 2020 01:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] 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 HugbM7_m40UO for ; Fri, 3 Jan 2020 01:35:22 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 165541201E5 for ; Fri, 3 Jan 2020 01:35:22 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A361FE607D; Fri, 3 Jan 2020 10:35:20 +0100 (CET) Date: Fri, 03 Jan 2020 10:35:20 +0100 (CET) Message-Id: <20200103.103520.394685109.sthaug@nethelp.no> To: sayrer@gmail.com Cc: dns@fl1ger.de, johnl@taugh.com, add@ietf.org, huitema@huitema.net From: sthaug@nethelp.no In-Reply-To: <20200103.103119.307223552.sthaug@nethelp.no> References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> <20200103.103119.307223552.sthaug@nethelp.no> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 09:35:23 -0000 > For those who wonder - why don't we simply drop this filtering: > > - The minister of justice at the time when this was introduced, Knut > Storberget, explicitly threatened to make the filter compulsory if > the ISPs didn't sign up on the "voluntary" use. See for instance > this article from 2008, in Norwegian: > https://www.nrk.no/norge/--ta-ansvar-mot-barneporno_-1.6203962 The actual letter is available here: https://file.wikileaks.org/file/norway-knut-storberget-censorship-2009.pdf Steinar Haug, AS 2116 From nobody Fri Jan 3 03:58:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B751200D7 for ; Fri, 3 Jan 2020 03:58:09 -0800 (PST) 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 k6Efq-5tR3HF for ; Fri, 3 Jan 2020 03:58:07 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15D81200D5 for ; Fri, 3 Jan 2020 03:58:06 -0800 (PST) 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 F26B66A262; Fri, 3 Jan 2020 12:58:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578052683; bh=g+XoJCKhvmsTonobQ1SBWMTiriXrstq0ZGM5NzG1Pg0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=14dbMlukS54AKiklZnQLWMX6RW2p+5H9+Fa2qYAYhbDVCguD48Bg97P+dgS/F9OAl vDY1w3UapmEJTwZ7Aw5/mZnSZAD8cZ/8Zpj9uHCDocWALKDqn/6l8zV2wOJ6SbIF7r IB2ey3FmxFnoZeEPggw+nNRDgUkSZgV/GQijC2fw9M+DklZA7IAYKUMz9gRy/Cq3TC 1gFm9pvS2z9ScF+hmQpEOBO+3SoQnvlXNHToDT9AWzvgCLuOmy9zGsL30TBTJieq3s LIIqqs/6B/wXL7OTHij3zRGwyAmeovJuIhZRaaWOVM0Ii8nyyI8QLF8N+ptPcTYFAo OLx5LxTCt2m/Q== 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 DB57F3C05BD; Fri, 3 Jan 2020 12:58:02 +0100 (CET) Date: Fri, 3 Jan 2020 12:58:02 +0100 (CET) From: Vittorio Bertola To: Brian Dickson , Adam Roach Cc: ADD Mailing list Message-ID: <1943235396.12345.1578052682802@appsuite-gw1.open-xchange.com> In-Reply-To: References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.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.3-Rev3 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] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 03 Jan 2020 11:58:09 -0000

Il 03/01/2020 00:30 Brian Dickson < brian.peter.dickson@gmail.com> ha scritto:

The client doesn't have to trust the services, if the data can be validated.
That's the whole point of DNSSEC, it does not require that the client trust the resolver.
If the goal of making DNS secure involved trusting resolvers, that could have been done by having resolvers AXFR the zones, and could have been done like 20 years ago.
That wasn't the model, and the design of DNSSEC specifically excludes that trust, precisely because of the underlying trust issues that show up when considering the privacy issues.

Trying to solve privacy issues by discarding the entire design and mode of operation of DNSSEC is a major step backwards, IMHO.
As I have been trying to explain confusedly with my lightning talk at the last OARC, I am afraid that the ship of interchangeable resolvers has sailed about ten years ago. Many modern DNS-based services, from CDNs to malware filtering, rely on the fact that you are using a specific resolver; same for other increasingly important features of a DNS resolution service, like speed and privacy. There is even a business pressure in this direction, as these are ways for the DNS operator to compete and draw customers, either to a paid DNS service (e.g. NextDNS, Mozilla's second TRR), or to a paid Internet access service (e.g. the ISP resolvers), or to a no-one-understands-the-business-model-yet public resolver (e.g. the "Quads").

I don't see that ship sailing back home - I rather see more competition coming. This is why the ability to discover and authenticate resolvers is so important for the entire industry (and also why we are seeing lots of antitrust arguments in legal and political venues).

So, on Adam's point:
Il 03/01/2020 00:56 Adam Roach < adam@nostrum.com> ha scritto:

Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

1. Do I trust the question I ask to be confidential? [1]
2. Do I trust the answer I get to be accurate?

Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.
The problem is that you cannot deal with resolver selection only from the viewpoint of privacy. You might devise a discovery mechanism that ensures total privacy, but if it also reduces choice and competition, or if it leads to slower performance, it will still harm the Internet.

The point is rather to empower users to choose their resolver in a reliable way, with as much choice as possible, and with their own personal tradeoff among all the possible features of a resolver; the new group's work should aim at that objective.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Fri Jan 3 07:14:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB21120046 for ; Fri, 3 Jan 2020 07:14:23 -0800 (PST) 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=K9hw8qgV; dkim=pass (1536-bit key) header.d=taugh.com header.b=OFu2dEJz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpOHolGP-ibn for ; Fri, 3 Jan 2020 07:14:21 -0800 (PST) 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 88A02120043 for ; Fri, 3 Jan 2020 07:14:21 -0800 (PST) Received: (qmail 25640 invoked from network); 3 Jan 2020 15:14:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6426.5e0f5a4c.k2001; i=johnl-iecc.com@submit.iecc.com; bh=F5bf96IVWJJEyf9JDFAUh6B4PI+6kCR0fP/SBhDrtk0=; b=K9hw8qgVzxIztFNr4DwfxDJggJ6/paYsAnQyqKA6QUlBVO3ohkCzaF82rG7O77a45ha9DDQ38+GqFK2ynEnxEl/80lq85Sj5RHRL2lfcdRkYRRMbU/JYD3mz1eDCNkyfGKSNJMRw3kPbyRP6G5l1WmP+4BK1/HKulvIBOffnQIhjQ/hHlbwPI1ccQLYkyTRJHSOPC/3ThtknKhroTABsIROAuX073O8Z07iOGCMbljGz5DiYmOj30XgfGAWc1Ggu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6426.5e0f5a4c.k2001; olt=johnl-iecc.com@submit.iecc.com; bh=F5bf96IVWJJEyf9JDFAUh6B4PI+6kCR0fP/SBhDrtk0=; b=OFu2dEJzhPcZ/dDiz24Vp7g8emYY1E6qO59UBn0Hd2euPB5r5UK4S3sQSJEU8LYmtkgIr6Bi2gBctXs1u/J1bSS5qg72oV4BqyMS30Wbm1Pkj7S6lU1gOF9Acc1sZOma+R6gzZgx9MbLtSJ4x03FBmVm0+PhxhepOt2MzkUnj8VuqvvtpDgP2hFY0ZwxyWZvCktCtHUf0rZnvwTEghwXPsZ7SihSUcpe/uHCIzEwRycjPFxdCejJTl5PEzX4GDQj 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 Jan 2020 15:14:20 -0000 Date: 3 Jan 2020 10:14:20 -0500 Message-ID: From: "John R Levine" To: sthaug@nethelp.no Cc: add@ietf.org In-Reply-To: <20200103.103119.307223552.sthaug@nethelp.no> References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> <20200103.103119.307223552.sthaug@nethelp.no> User-Agent: Alpine 2.21.99999 (OSX 374 2019-10-27) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 15:14:23 -0000 On Fri, 3 Jan 2020, sthaug@nethelp.no wrote: > Since this is not directly "required by law", we (AS 2116) could not > agree to the current Mozilla TRR policy. > > (For those who wonder - why don't we simply drop this filtering: Thanks. This is a good example of why a lot of formulations of the "policy" problem are hopelessly naive. I gather that your situation is the norm in most of Europe. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Jan 3 08:12:40 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F71120043 for ; Fri, 3 Jan 2020 08:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 2bZJhKIYgKLd for ; Fri, 3 Jan 2020 08:12:35 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id A723A12000F for ; Fri, 3 Jan 2020 08:12:35 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id D17F8E6079; Fri, 3 Jan 2020 17:12:32 +0100 (CET) Date: Fri, 03 Jan 2020 17:12:32 +0100 (CET) Message-Id: <20200103.171232.60420162.sthaug@nethelp.no> To: johnl@taugh.com Cc: add@ietf.org From: sthaug@nethelp.no In-Reply-To: References: <20200103.103119.307223552.sthaug@nethelp.no> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 16:12:39 -0000 >> Since this is not directly "required by law", we (AS 2116) could not >> agree to the current Mozilla TRR policy. >> >> (For those who wonder - why don't we simply drop this filtering: > > Thanks. This is a good example of why a lot of formulations of the > "policy" problem are hopelessly naive. I gather that your situation > is the norm in most of Europe. I don't know if it's the norm. I *do* know that Norway is certainly not alone in using such child porn filtering. Steinar Haug, AS 2116 From nobody Fri Jan 3 08:16:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACE5120043 for ; Fri, 3 Jan 2020 08:16:32 -0800 (PST) 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 luEX5Fzn4Qsi for ; Fri, 3 Jan 2020 08:16:31 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 B802512000F for ; Fri, 3 Jan 2020 08:16:30 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id j26so44350700ljc.12 for ; Fri, 03 Jan 2020 08:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w3NuHCR1fScbnONoxfllgDdOggxIo/mjC3/gLDMi0Ec=; b=MRg1pkm4g8W2bdyac5NOBIN7n1k4lHzL0BuqVBARViI0mpSzNYwU7Q+1BGBryHlrqb OxKVvfueUkwPfPH3kUtJupxGLsrqbNwYGanl8t8tM93rzAtrawaIFv8NN8lV5gEFZClp M3LAkaRDn/YsdqZMO75/4IMiPnAfuiL5c8q5YQfRCEC24gccpF+MO0hMGl6wFfvdFJ2+ yVLgVSjab1u3n4t3d3A8MArahfgoNU4ap6VcLu1AK69sYqaFtHhCGbpI8hYT76kyF249 CKMzLx8MbtCtdd6wJeu1skx32k5t0o/ckM8RsruPS2TQ1h19b5iPBY/EchWD2vrZ9Ku+ wwpA== 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=w3NuHCR1fScbnONoxfllgDdOggxIo/mjC3/gLDMi0Ec=; b=jNuhoa1wg1iC4/wQ7thTAHxgGKE6FLuHhsV2SP1NKPd5UPQAbqtiFUgzOvTsBC2IkV SNNIg1FmMXMDUOgHzjVVbkyLywo+JS9gHoVwTvTZ5hyx+wZJE/XdAl2hlvm7THfwF98R bnj4AP9T/QWHwW51u2I711TRn59im06TQ4vdaCXyINserLfuPGYJfIXk/ybT3M8eGUzq wQ1WZ9KX9aDqKK/168taIiuz+6gPBtxcmQxvzKlgCwAFcaaJEE43RDYFwYEpTpeDtMdh rxX7SVFl8ej/Ue6QlYCVlUvaMKQVNBlkSfHhuo+ZtOGPllTefm1a+bkh4QYFOxe5Jy0a EdkA== X-Gm-Message-State: APjAAAUiInItS2CZQu4oeAAJkzE16AZqYnQq/cecGPm33KhfHKu8eCec G06fsgWLVuQ89HAtPMheUmHEYt/mc+gq4NV0EFznrA== X-Google-Smtp-Source: APXvYqyK3AFWBIpHcFmXCDeUaUoYrq/4yaji65avesJMZLnPZvLtljVwuHwzm7rcNN2jixWoHqA8/iTHgRtGolHlw74= X-Received: by 2002:a2e:88c5:: with SMTP id a5mr53324076ljk.201.1578068188971; Fri, 03 Jan 2020 08:16:28 -0800 (PST) MIME-Version: 1.0 References: <20191231020124.5B7DB11D768C@ary.qy> <6445ae87-a7d7-abf0-a54c-5f9500f677ef@huitema.net> <0D29CDBF-54CF-4D84-95FB-11141E9B0E56@fl1ger.de> <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> In-Reply-To: From: Eric Rescorla Date: Fri, 3 Jan 2020 08:15:52 -0800 Message-ID: To: Rob Sayre Cc: Ralf Weber , John Levine , ADD Mailing list , Christian Huitema Content-Type: multipart/alternative; boundary="000000000000d5d786059b3ea1a5" Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 16:16:32 -0000 --000000000000d5d786059b3ea1a5 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 2, 2020 at 11:48 PM Rob Sayre wrote: > On Thu, Jan 2, 2020 at 10:44 PM Ralf Weber wrote > > >> And as shown by others switching DNS resolution to a central provider > > does not actually take away information from the network provicder, but >> merly adds another party that now also has your data: >> >> https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/ > > > Not sure about "as shown". Concerns about governmental jurisdiction seem > fair, but what's stopping a European company from agreeing to a TRR policy? > (from anyone they trust, not only Mozilla) > > The other concerns in that post might be accurate for the moment (e.g., > those about SNI), but they don't really make a compelling case to preserve > the status quo. > The SNI argument seems a little odd here, given that (1) we are actively working on encrypting SNI and (2) concealing the DNS queries is essential to making ESNI work. -Ekr --000000000000d5d786059b3ea1a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 11:48 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Thu, Jan 2, 2020 at 10:44 PM Ralf Weber &l= t;dns@fl1ger.de> = wrote
=C2=A0
And as shown by others switching DNS resolution to a central provider=C2=A0=
does not actually take away information from the network provicder, but
merly adds another party that now also has your data:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://blog.powerdns.com/2019/09/25/centralised-doh-is-= bad-for-privacy-in-2019-and-beyond/

Not= sure about "as shown". Concerns about governmental jurisdiction = seem fair, but what's stopping a European company from agreeing to a TR= R policy? (from anyone they trust, not only Mozilla)

The other concerns in that post might be accurate for the moment (e.g., = those about SNI), but they don't really make a compelling case to prese= rve the status quo.

The = SNI argument seems a little odd here, given that (1) we are actively workin= g on encrypting SNI and (2) concealing the DNS queries is essential to maki= ng ESNI work.

-Ekr
--000000000000d5d786059b3ea1a5-- From nobody Fri Jan 3 08:28:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E297120033 for ; Fri, 3 Jan 2020 08:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 Fdns7vm5YjsA for ; Fri, 3 Jan 2020 08:28:21 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 3C15712000F for ; Fri, 3 Jan 2020 08:28:21 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id w127so34146528qkb.11 for ; Fri, 03 Jan 2020 08:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QD4f7ab+3OW3OnzHMpZT74fxu0/SuzwECev57xYtHsQ=; b=KKU4N3BFtiDXAU799Z13uAGJ0oO+QdqKBegAyTLruLrVFG3GIyDC7vQN/15SEoB3bG PX/w8dsGFpKDBYqIdLnCDAEpeB0WOlyY3nsTm+KEEn7PAxWPEmx3lF6bN1KzrtOJESL0 A+ORfvRwTjwiNCbv/HKNnQHFjFFZ8A0sWlqO1gS27k1FarNnRyXEs78f6ibQQaHcxwwb QLresTW0bSFsAA/EtAQEsUBEY3E1ATVw0EGF6l7owQo0CY7K6t6a1gNha/wj8y5ez2cc UUj/Kg416eEp4rgtBMLRfabsNxmqsRIY/NpK/E2d9NPVKKgc7OQOx3mB4Abm/mU/Pg+Q dLGQ== 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=QD4f7ab+3OW3OnzHMpZT74fxu0/SuzwECev57xYtHsQ=; b=oDiNoXhoAP88Q6gPV1ef2Cuc7wfMHSObZwY1QqyIJT/HHFVuFMypAGC85KUpNMOHEC /ERuWnOnz0WM0LbXoZ34rY6GEs6sohxrlR9wReALtmQiEo/tLZAqchn1SEsaywrSap+c NkG5+CMrOQ/imueI1aTeE8v3GohbVRW1fXkhgah5Aeguxl4+RwY2UCnHNXo8I+8PzeZy uh9iTGy3wj5oA4PUZ7cytNlZXAO2FORusz7wQV4m8KJPQMy7I9WZvIUxc4Rgd3p0hyhi 2hVNYN9d98k+UEWP+v9zBCbKqrCUHe97jtImLjGLH3cIwOLB5Swl1YLFbTwG9cLnRqKU 8WrA== X-Gm-Message-State: APjAAAXtzCMVoMRISWqEb0JQYGObp2KRC8W2GIik0qjPQgKly/rYw0Er k9p8OrWeLicr6Yf4gTEWGkIg0A== X-Google-Smtp-Source: APXvYqwSVGC9SxMCpJttK868DHLDtf9v8c7xKYPvfXQ6tVZtUYo9PxLQi4856PcEwGUD6pNLDdVbcg== X-Received: by 2002:a37:b946:: with SMTP id j67mr68671500qkf.35.1578068900372; Fri, 03 Jan 2020 08:28:20 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:f412:63d9:a57a:717c? ([2601:18b:300:36ee:f412:63d9:a57a:717c]) by smtp.gmail.com with ESMTPSA id e3sm17158327qtj.30.2020.01.03.08.28.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 08:28:19 -0800 (PST) From: Ted Lemon Message-Id: <41DAEB3C-B97B-497D-A7A7-1C0585487747@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_390EBEB5-15DB-443B-B45E-BDECEE21BBCB" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Fri, 3 Jan 2020 11:28:18 -0500 In-Reply-To: <20200103.103119.307223552.sthaug@nethelp.no> Cc: sayrer@gmail.com, huitema@huitema.net, add@ietf.org, johnl@taugh.com, dns@fl1ger.de To: sthaug@nethelp.no References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> <20200103.103119.307223552.sthaug@nethelp.no> X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 16:28:23 -0000 --Apple-Mail=_390EBEB5-15DB-443B-B45E-BDECEE21BBCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 3, 2020, at 4:31 AM, sthaug@nethelp.no wrote: > However, we also block "child porn" domains. This is a voluntary > agreement and as such is not covered by "required by law". This is > done by all large Norwegian providers, see This problem is easily solved: stop blocking the domains voluntarily and = encourage your government to enact the law. Why should this be done on = a pseudo-voluntary basis? If there is a public policy benefit to doing = it, why not have an actual public policy? --Apple-Mail=_390EBEB5-15DB-443B-B45E-BDECEE21BBCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 3, 2020, at 4:31 AM, sthaug@nethelp.no wrote:
However, we also block "child porn" domains. This is a = voluntary
agreement and = as such is not covered by "required by law". This is
done by all = large Norwegian providers, see

This problem is easily solved: stop blocking = the domains voluntarily and encourage your government to enact the law. =  Why should this be done on a pseudo-voluntary basis?   If = there is a public policy benefit to doing it, why not have an actual = public policy?

= --Apple-Mail=_390EBEB5-15DB-443B-B45E-BDECEE21BBCB-- From nobody Fri Jan 3 08:43:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1905120091 for ; Fri, 3 Jan 2020 08:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 O4k1V3vUE0lH for ; Fri, 3 Jan 2020 08:43:28 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3FAD12008F for ; Fri, 3 Jan 2020 08:43:27 -0800 (PST) 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 1D9436A257; Fri, 3 Jan 2020 17:43:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578069804; bh=kjZ31PmZwmAvXj2ZsOVGk7rul6IcQd1bnb2aaIHV+Nw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=G+DWlz/V8ww7ib24ZK2ABaOsCA//TC0JcRzh7HF9Twb7sKtP0tFD5A63x3oS7Uyz4 IN3Hu/BAi2qCCTPaokNX6SVFW92Dn8j1VdiHG98nWYq+d5wYr9+SkKkTeFXyacICnW 2u+XcHz2GKytPaA9wA1QIdXa5FYVQMP4QUpfitScXtduHgTdpOWLVPwXxiG18z7px/ BujSnjxMIn6TRxqmPsb9xDWdB9YQ7TOEbKl447OTXaGiVPlL1IWgydGuSI3FtsHyW2 PMIx8KSTTyQ+UnBwAfO2e99WwL3zJ6mCbsEBQiSKHt4Y67fxQpQBBzhusBGHb6dXpg eJVB0fsaeLhRQ== 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 10A1B3C0363; Fri, 3 Jan 2020 17:43:24 +0100 (CET) Date: Fri, 3 Jan 2020 17:43:23 +0100 (CET) From: Vittorio Bertola To: sthaug@nethelp.no Cc: add@ietf.org Message-ID: <627722957.12964.1578069803971@appsuite-gw1.open-xchange.com> In-Reply-To: <20200103.171232.60420162.sthaug@nethelp.no> References: <20200103.103119.307223552.sthaug@nethelp.no> <20200103.171232.60420162.sthaug@nethelp.no> 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.3-Rev3 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: [Add] Filtering in the EU (was Re: Data sharing can not be detected with open resolvers) X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 16:43:30 -0000 > Il 03/01/2020 17:12 sthaug@nethelp.no ha scritto: > > > Thanks. This is a good example of why a lot of formulations of the > > "policy" problem are hopelessly naive. I gather that your situation > > is the norm in most of Europe. > > I don't know if it's the norm. I *do* know that Norway is certainly > not alone in using such child porn filtering. The UK has basically the same approach as Norway; in other European countries (the ones within the EU) there often are actual laws and/or public authority orders, though. In fact, in the EU this is the subject of an ongoing policy debate, as the European network neutrality regulation requires that any "in-network" filtering by ISPs happens because of a national law (or of network security), but it is arguable whether DNS filtering happens at the network layer or at the application layer, so the regulatory body tasked with interpreting the regulation has recently put out a proposal that says that DNS filtering is allowed on "secondary DNS resolvers" but not on "primary DNS resolvers", so there were plenty of comments, half of which suggested that it would be really bad to allow filtering on "secondary DNS resolvers", while the other half suggested that it would be really bad to disallow filtering on "primary DNS resolvers", though in the end no one really understands what they are and how to tell a "primary DNS resolver" from a "secondary DNS resolver". So yes, a lot of fun (and a lot of unclear liabilities for ISPs, no matter what they do). (And to Ted's objection: I agree with you, governments should just pass laws, but it takes time and effort and it is subject to political risks, so it's just easier for them to rely on self-regulation; and in the end, no operator, except maybe very small "militant" ones, would ever want to favour child abuse in any way, or even just to pass publicly for the one that does not want to block child abuse.) -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Jan 3 08:58:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A67120854 for ; Fri, 3 Jan 2020 08:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyF4_wMkuzJ7 for ; Fri, 3 Jan 2020 08:58:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1345012083B for ; Fri, 3 Jan 2020 08:58:28 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 003GwNpv097701 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Jan 2020 10:58:25 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578070705; bh=qgN3M5Zs/JC48XJsK+JtmIvoxvzHVIqpcrxOBtn7p/M=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=uBROgKeCcZ1hW3pdfU/JJAayflU+VGb2kW9Vdqo1gPhYZpzcRqUQCeSSCAFQMTVCP WyOcZr/tP8YwI1kU/M6hdjJ5LNZyudddRgv72E7q8SqN815YckbDN+VeWJvXMlQeH9 kFkDki+jfI4Mhdf7ETYaErGbDVEp5ljT5+rLpMJk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Vittorio Bertola , Brian Dickson Cc: ADD Mailing list References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <1943235396.12345.1578052682802@appsuite-gw1.open-xchange.com> From: Adam Roach Message-ID: Date: Fri, 3 Jan 2020 10:58:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1943235396.12345.1578052682802@appsuite-gw1.open-xchange.com> Content-Type: multipart/alternative; boundary="------------FFA5BADE145816F81D4679B0" Content-Language: en-US Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 03 Jan 2020 16:58:33 -0000 This is a multi-part message in MIME format. --------------FFA5BADE145816F81D4679B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/3/20 5:58 AM, Vittorio Bertola wrote: > So, on Adam's point: >> Il 03/01/2020 00:56 Adam Roach < adam@nostrum.com >> > ha scritto: >> >> Having read through this thread, I think there is a useful >> charter-related distinction to be made here, and I think conflating >> these two things may be one reason people are talking past each other: >> >> 1. Do I trust the question I ask to be confidential? [1] >> 2. Do I trust the answer I get to be accurate? >> >> Given that the only context apparently under discussion is web >> browsers, and given that the vast majority of HTTP connections are >> performed over TLS [2] [3], I suspect that #1 is the far more >> interesting question, and the only one that really makes sense to >> focus on in the charter. > The problem is that you cannot deal with resolver selection only from > the viewpoint of privacy. You might devise a discovery mechanism that > ensures total privacy, but if it also reduces choice and competition, > or if it leads to slower performance, it will still harm the Internet. > > The point is rather to empower users to choose their resolver in a > reliable way, with as much choice as possible, and with their own > personal tradeoff among all the possible features of a resolver; the > new group's work should aim at that objective. Without agreeing or disagreeing with what you say above, I want to clarify that you missed my point. I tried to be clear -- especially in footnote [1] of my message -- that there is a lot of additional nuance behind question 1, and you're definitely getting at some of it. But the sole thesis of the message you quote above is that people are using "trust" to mean two different, mostly unrelated things, and that only one of them is interesting in the context under discussion. /a --------------FFA5BADE145816F81D4679B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/3/20 5:58 AM, Vittorio Bertola wrote:
So, on Adam's point:
Il 03/01/2020 00:56 Adam Roach < adam@nostrum.com> ha scritto:

Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

1. Do I trust the question I ask to be confidential? [1]
2. Do I trust the answer I get to be accurate?

Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.
The problem is that you cannot deal with resolver selection only from the viewpoint of privacy. You might devise a discovery mechanism that ensures total privacy, but if it also reduces choice and competition, or if it leads to slower performance, it will still harm the Internet.

The point is rather to empower users to choose their resolver in a reliable way, with as much choice as possible, and with their own personal tradeoff among all the possible features of a resolver; the new group's work should aim at that objective.


Without agreeing or disagreeing with what you say above, I want to clarify that you missed my point. I tried to be clear -- especially in footnote [1] of my message -- that there is a lot of additional nuance behind question 1, and you're definitely getting at some of it. But the sole thesis of the message you quote above is that people are using "trust" to mean two different, mostly unrelated things, and that only one of them is interesting in the context under discussion.

/a

--------------FFA5BADE145816F81D4679B0-- From nobody Fri Jan 3 09:02:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11D612008F for ; Fri, 3 Jan 2020 09:02:54 -0800 (PST) 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 tiy0-Yt2i9A6 for ; Fri, 3 Jan 2020 09:02:53 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E62120088 for ; Fri, 3 Jan 2020 09:02:53 -0800 (PST) Received: from [172.16.46.86] (unknown [113.160.150.145]) (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 38B64242153A; Fri, 3 Jan 2020 17:02:49 +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: <41DAEB3C-B97B-497D-A7A7-1C0585487747@fugue.com> Date: Fri, 3 Jan 2020 17:02:46 +0000 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> <20200103.103119.307223552.sthaug@nethelp.no> <41DAEB3C-B97B-497D-A7A7-1C0585487747@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 17:02:55 -0000 > On 3 Jan 2020, at 16:28, Ted Lemon wrote: >=20 > This problem is easily solved: stop blocking the domains voluntarily = and encourage your government to enact the law. Comments like this are unhelpful. They can result in governments passing = legislation that has even worse implications for privacy and security. = [Remember the Australian politician who said crypto in that country = would be determined by the laws of Australia and not those of = mathematics?] And FWIW you might as well be telling criminals to stop = breaking the law for all the good that would do too. > Why should this be done on a pseudo-voluntary basis? Because the legislative cycle can take too long and can't keep up with = technology. You might recall legislators were still trying to figure out = how to deal with Napster long after the IPR lawyers got those sorts of = services shut down. > If there is a public policy benefit to doing it, why not have an = actual public policy? The policy is generally publicised as "block child abuse imagery" and = ISPs are left to sort out the implementation details. Sometimes they = choose DNS-based approaches. Sometimes they don't. And from an ISP's = perspective, voluntarily adopting some blocklist means they have less = exposure to prosecution or other forms of court action. Or spending = money to develop and maintain their own blocklists with all the risks = that that brings. The public policy benefit is having a mechanism that, while not = foolproof, is "good enough". It stops the stupidest criminals accessing = illegal content so that law enforcement can concentrate their resources = on the more sophisticated offenders who are using VPNs or P2P or = whatever. The politicians can also show to their voters that Something = Has Been Done about the problem. From nobody Fri Jan 3 12:54:32 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95C6120099 for ; Fri, 3 Jan 2020 12:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 i3s-UDxW14J1 for ; Fri, 3 Jan 2020 12:54:28 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 C5004120045 for ; Fri, 3 Jan 2020 12:54:28 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id t17so37552615ilm.13 for ; Fri, 03 Jan 2020 12:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LUVS+y289SIA97cQPJuqHmfoTqWkzz10M4kMpZqkopk=; b=S1Jxaz92S/rNSg13UW+lgEsPk/JyE4SQsa33zblNBfE3HdNxErvW4ONP7f5X5fxayg R1mBpY7ecIB1bAahCLuurFIIdpVR4k+JKYKbgWMWEEwycXLzXDRXRL1ns3D3AY9io6Zt VGmTqAH19OF4mFnaG6c9CgdTWQ0nufVunPmnL6OnnTo22d9ssjHdsy9UA359jU5wpTGa XiJGgDrX6EvZt+Ux9rk7cmrUgXj9HYhlIdd+XQ1yVDERQq1rMullQ7RBcaadCFLuauID VqrZs07hVfF0MpyQdXj+zSWSZvlCTEW2CA12z5A56Ff8OO/b/Egq6Fpi8toKiGXl3Nf6 btdw== 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=LUVS+y289SIA97cQPJuqHmfoTqWkzz10M4kMpZqkopk=; b=LxsonNcuWOtqllaMiBOAAZHTIirF3NPmXQr0AQ5O86Z5aDCfZmc8wOAs14N+jJJWrm TaYDmcNYfCssxLteyMnHez7ViDQgOnGTgN7FKgXlquUtcqZ7r2UjwhdZaPw4DY7JiKWN /ixJyXTzvLIaJ9vOYyL9d877SqYBAs8JfnrDjg6OYPVQgh5/2TVoYXXZEhrccjRBIFi/ ekTtMa6wHUOVa7ViNCVUx8DQnIsCnkQ4paC/Na5b1MldRKCmTpYbVy344Z1+LhsfZOiQ pTIhDw8jLny3O1hf8ZfUkXZUVhCdrVRUbLvES2UszEo8H7+KDyXDBXMw2p73ZBDSiG0k 46WA== X-Gm-Message-State: APjAAAXapCp4CqhP/dw0bQtm8Y99WEdtuZwmEbRlK27qB2M7PQkQh2dD tsCKNdqxQLKjWyMPzC6Bd4VofIsUznuKiDzPWcp+WRnH X-Google-Smtp-Source: APXvYqzRvrWb6dBe/LbUhDTspoF3RB6+ChTMjxiLwqc7jzgwPu33vIf1GMyUpuE/x8e5WClSwLuwni5wb72/Dt7sarc= X-Received: by 2002:a92:4514:: with SMTP id s20mr60801464ila.254.1578084867910; Fri, 03 Jan 2020 12:54:27 -0800 (PST) MIME-Version: 1.0 References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> <20200103.103119.307223552.sthaug@nethelp.no> <41DAEB3C-B97B-497D-A7A7-1C0585487747@fugue.com> In-Reply-To: From: Rob Sayre Date: Fri, 3 Jan 2020 12:54:16 -0800 Message-ID: To: Jim Reid Cc: Ted Lemon , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000fa44d1059b42839b" Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 20:54:31 -0000 --000000000000fa44d1059b42839b Content-Type: text/plain; charset="UTF-8" On Fri, Jan 3, 2020 at 9:03 AM Jim Reid wrote: > > The public policy benefit is having a mechanism that, while not foolproof, > is "good enough". > Another person on this thread used the term "easy to evade". I agree that the public policy concern is valid, but doubt the effectiveness of DNS-based solutions, and don't think the IETF /can/ design protocols around unstated policies. Again, it's probably better to focus on concrete use cases. While some of what's quoted below is not controversial functionality, other parts could clearly raise concerns, and lead a user to prefer an alternate DNS provider (even as a default). Here are some quotes: "CSPs don't need to invest in big data platforms or systems to get this type of knowledge about subscribers--they already have access to the data through DNS. Because it powers virtually every web site, service and application request made, DNS is perfectly suited to gain granular insights about subscribers and other members of their households..." https://blogs.akamai.com/2016/06/whats-in-a-name-leveraging-dns-to-personalize-services.html "In fact, the use of DNS--which already exists in CSP networks--has over 70 different business use cases that have been identified by Nominum, now part of Akamai. ... DNS: not just for domain lookups anymore The areas where we've identified use cases span organizations and functions. They include: - cybersecurity defense - value-added services - customer experience management - marketing and promotions - billing and revenue management - legal and regulatory compliance" https://blogs.akamai.com/201/05/cross-organizational-use-cases-show-value-of-dns-in-digital-transformation.html thanks, Rob --000000000000fa44d1059b42839b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 3, 2020 at 9:03 AM Jim Reid &= lt;jim@rfc1035.com> wrote:

The public policy benefit is having a mechanism that, while not foolproof, = is "good enough".

Another per= son on this thread used the term "easy to evade". I agree that th= e public policy concern is valid, but doubt the effectiveness of DNS-based = solutions, and don't think the IETF /can/ design protocols around unsta= ted policies.

Again, it's probably better to f= ocus on concrete use cases. While some of what's quoted below is not co= ntroversial functionality, other parts could clearly raise concerns, and le= ad a user to prefer an alternate DNS provider (even as a default).

Here are some quotes:

"CSPs = don't need to invest in big data platforms or systems to get this type = of knowledge about subscribers--they already have access to the data throug= h DNS. Because it powers virtually every web site, service and application = request made, DNS is perfectly suited to gain granular insights about subsc= ribers and other members of their households..."

<= div>https://blogs.akamai.com/2016/06/whats-in= -a-name-leveraging-dns-to-personalize-services.html

<= /div>

"In fact, the use of DNS--which already exist= s in CSP networks--has over 70 different business use cases that have been = identified by Nominum, now part of Akamai.
...
DNS: not= just for domain lookups anymore
The areas where we've identified us= e cases span organizations and functions. They include:
- cybersecurity = defense
- value-added services
- customer experience management
- = marketing and promotions
- billing and revenue management
- legal and= regulatory compliance"


thanks,
Rob

=
--000000000000fa44d1059b42839b-- From nobody Fri Jan 3 16:28:40 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAEB1200E9 for ; Fri, 3 Jan 2020 16:28:38 -0800 (PST) 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, 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, 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=microsoft.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 pRWPjvyUN9zX for ; Fri, 3 Jan 2020 16:28:36 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650093.outbound.protection.outlook.com [40.107.65.93]) (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 CF0B6120020 for ; Fri, 3 Jan 2020 16:28:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRzK/YJOl3z5DXCbIPEBpzAhEHr/08ura6Z3t5c6mMgRslLoOZgM189qJKT5h2kPH/PTkVwIZ9NTFPGwVJgu2PAtcUuYqA6eT94966PNXS7hdgziNRSG3j0n3kTgLO9tl3FOOyTxUtxgRb7O20JGdGWp6nq00nqCDHOZ3kI3D6ncAA6NnAo9o5gUdqHAdMMGAs07SGCUjTwwzSwP2zGVS8p/ojDYxQzrnFVAzLrIITK9/IXv1X2ZBDvl4x34pJ3PkS2I7iZDkNUDrwqtSQ6TxzcxLnttrTJ7pHUh/fhSMVREhvzErrbYngkh6M4UuiFvKdgNyJs+CzLmWBlRBDVwIw== 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=r/PXMVSrXH4QCYVRj7sM78JHA4GDForgChqc9S+v7+A=; b=Zg8saJTR+pW6DkasGJetoLTtSxuwyctaDMlNl83/44NmfkFEMW54BXgfV1r8cNojirXFcaHi7oBap49B9OKxHIfcwOor4OXrghmZtX4CUc9yynkrD1++3bhcGH0FgF5VJ4H8eAskcsE8TI3QmJjB7p++HJ6S1KA3aYS9tfh6QcnCOF7zdfYOm8wy8jOD5rVeaZkccioi2glEoBJnI+43O2BB3FTMOUA9OgYO7P2vHFjuF/JDQnwhyLR3pGVjIy8UyaKvKstPnigoTvb+ZU1KbvK6n166sBlvOinWxtv0GzA3bbVXP8OGiLdF7an83/7+NHBFdSrScOL2ND3GD0/dkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r/PXMVSrXH4QCYVRj7sM78JHA4GDForgChqc9S+v7+A=; b=R8t5OkgJpT9SHADr7+op0s6hHctgEpMM9Z6olmqucim9OVXcdXt41IgBEPtQWGpyA+A1BmQ6gwrxSURb7rhT081L5C4+RREJeDx/PlWJ6Uhgcu76SEWTCAH2Cg2MBF1/03VrRwKV2+Q3GR0hg3ucT1pMn+C82xSIjV4t2Py1/xQ= Received: from MN2PR00MB0463.namprd00.prod.outlook.com (20.178.240.145) by MN2PR00MB0607.namprd00.prod.outlook.com (20.179.20.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2648.0; Sat, 4 Jan 2020 00:28:33 +0000 Received: from MN2PR00MB0463.namprd00.prod.outlook.com ([fe80::357e:3974:ca07:f614]) by MN2PR00MB0463.namprd00.prod.outlook.com ([fe80::357e:3974:ca07:f614%3]) with mapi id 15.20.2645.000; Sat, 4 Jan 2020 00:28:33 +0000 From: Tommy Jensen To: Adam Roach , Vittorio Bertola , Brian Dickson CC: ADD Mailing list Thread-Topic: [EXTERNAL] Re: [Add] A proposed charter for ABCD Thread-Index: AQHVuZ2EYtyJ/U7FY06jkVfGxrVtPKfJsGGAgAAIloCADOpQAIAAJ/WAgAAcb4CAAEwKAIAARewAgAB3IwCAAB/XAIAABVkAgADQ6gCAAFPlAIAAe+fy Date: Sat, 4 Jan 2020 00:28:32 +0000 Message-ID: References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <1943235396.12345.1578052682802@appsuite-gw1.open-xchange.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-04T00:28:30.868Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [2001:4898:80e8:a:a968:512c:73e5:d312] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 05a4eb4f-d9a6-45a2-c5d8-08d790ad07f4 x-ms-traffictypediagnostic: MN2PR00MB0607: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(136003)(39860400002)(366004)(189003)(199004)(71200400001)(2906002)(19627405001)(76116006)(66946007)(66446008)(64756008)(66556008)(66476007)(66574012)(33656002)(4326008)(6506007)(53546011)(8936002)(186003)(478600001)(55016002)(8990500004)(10290500003)(7696005)(9686003)(316002)(110136005)(86362001)(8676002)(81166006)(52536014)(5660300002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0607; H:MN2PR00MB0463.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 13iuaWvnzn1HfaRNxGn019lcIBbXZ+zc49OGgQDQOX8MfH8WR0FT99mGRcl1nS5iH8WBNASF2w43yXIIE5GfOl15KipGQlDeBkvFM5gQYdY3Lyb54joqnjALpKNz7vbwdzX6zPxuszPahtE5OQacMv6hDu+5IHlCMlWMVaqhoHsUKcAB7YWs+buhXcWTV6gbuAALiyGlXO+JG+nHcRbsWysElY4amTdQLUv4+NUp5havGTQMu2bRMZdNW6jK0zxH2tgNaa5V7p3jZOxuaD+KDpHjGQN2dTKZlDwEA1Kex4J+KP+zD51DY9pAZglR10kdF97x1TJm61H8wlFB+/uOGHcKzGb9eSoLOy43iRbtlB/URQKGFaYLj545v1lMfY7HoztTS8+2hOb8jdv3YkF5L5U+SKp+eWgFIoAln0jVzOPMjUEZial9y73KL9O79hQU x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB04634056F4E5E492A32D1986FA220MN2PR00MB0463namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 05a4eb4f-d9a6-45a2-c5d8-08d790ad07f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2020 00:28:33.0639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EqSvTQcfAJ/9MogQziNm8AE6wK32AirGNsYVA7+wptgex1XXM8SzAe49tkSSaR/6ceMb0Z8eXzZjDhYxZtAhNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0607 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 04 Jan 2020 00:28:38 -0000 --_000_MN2PR00MB04634056F4E5E492A32D1986FA220MN2PR00MB0463namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable adam>> But the sole thesis of the message you quote above is that people ar= e using "trust" to mean two different, mostly unrelated things, and that on= ly one of them is interesting in the context under discussion. +1. The accuracy of the answer (your #2) is a problem that exists whether t= he DNS delivery mechanism is encrypted or not, as has been hinted at alread= y on this thread. It also has existing solutions. I agree that your #1 (con= fidentiality) should be our primary focus so we can nail down a charter bef= ore we go even longer without an IETF WG on the matter. Thanks, Tommy ________________________________ From: Add on behalf of Adam Roach Sent: Friday, January 3, 2020 8:58 AM To: Vittorio Bertola = ; Brian Dickson Cc: ADD Mailing list Subject: [EXTERNAL] Re: [Add] A proposed charter for ABCD On 1/3/20 5:58 AM, Vittorio Bertola wrote: So, on Adam's point: Il 03/01/2020 00:56 Adam Roach < adam@nostrum.com>= ha scritto: Having read through this thread, I think there is a useful charter-related = distinction to be made here, and I think conflating these two things may be= one reason people are talking past each other: 1. Do I trust the question I ask to be confidential? [1] 2. Do I trust the answer I get to be accurate? Given that the only context apparently under discussion is web browsers, an= d given that the vast majority of HTTP connections are performed over TLS [= 2] [3], I suspect that #1 is the far more interesting question, and the onl= y one that really makes sense to focus on in the charter. The problem is that you cannot deal with resolver selection only from the v= iewpoint of privacy. You might devise a discovery mechanism that ensures to= tal privacy, but if it also reduces choice and competition, or if it leads = to slower performance, it will still harm the Internet. The point is rather to empower users to choose their resolver in a reliable= way, with as much choice as possible, and with their own personal tradeoff= among all the possible features of a resolver; the new group's work should= aim at that objective. Without agreeing or disagreeing with what you say above, I want to clarify = that you missed my point. I tried to be clear -- especially in footnote [1]= of my message -- that there is a lot of additional nuance behind question = 1, and you're definitely getting at some of it. But the sole thesis of the = message you quote above is that people are using "trust" to mean two differ= ent, mostly unrelated things, and that only one of them is interesting in t= he context under discussion. /a --_000_MN2PR00MB04634056F4E5E492A32D1986FA220MN2PR00MB0463namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
adam>> But the sole thesis of the message you quote above is tha= t people are using "trust" to mean two different, mostly unrelate= d things, and that only one of them is interesting in the context under dis= cussion.

+1. The accuracy of the answer (your #2) is a problem that exists wheth= er the DNS delivery mechanism is encrypted or not, as has been hinted at al= ready on this thread. It also has existing solutions. I agree that your #1 = (confidentiality) should be our primary focus so we can nail down a charter before we go even longer without an IE= TF WG on the matter.

Thanks,
Tommy

From: Add <add-bounces@ietf.org> on behalf of Adam Roach= <adam@nostrum.com>
Sent: Friday, January 3, 2020 8:58 AM
To: Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc= .ietf.org>; Brian Dickson <brian.peter.dickson@gmail.com>
Cc: ADD Mailing list <add@ietf.org>
Subject: [EXTERNAL] Re: [Add] A proposed charter for ABCD
 
On 1/3/20 5:58 AM, Vittorio Bertola wrote:=
So, on Adam's point:
Il 03/01/2020 00:56 Adam Roach < adam@nostrum.com> ha scritto:

Having read through this thread, I think there is a useful charter-rel= ated distinction to be made here, and I think conflating these two things m= ay be one reason people are talking past each other:

1. Do I trust the question I ask to be confidential? [1]
2. Do I trust the answer I get to be accurate?

Given that the only context apparently under discussion is web browser= s, and given that the vast majority of HTTP connections are performed over = TLS [2] [3], I suspect that #1 is the far more interesting question, and th= e only one that really makes sense to focus on in the charter.
The problem is that you cannot deal with resolver selection only from = the viewpoint of privacy. You might devise a discovery mechanism that ensur= es total privacy, but if it also reduces choice and competition, or if it l= eads to slower performance, it will still harm the Internet.

The point is rather to empower users to choose their resolver in a rel= iable way, with as much choice as possible, and with their own personal tra= deoff among all the possible features of a resolver; the new group's work s= hould aim at that objective.


Without agreeing or disagreeing with what you say above, I want to clari= fy that you missed my point. I tried to be clear -- especially in footnote = [1] of my message -- that there is a lot of additional nuance behind questi= on 1, and you're definitely getting at some of it. But the sole thesis of the message you quote above is that = people are using "trust" to mean two different, mostly unrelated = things, and that only one of them is interesting in the context under discu= ssion.

/a

--_000_MN2PR00MB04634056F4E5E492A32D1986FA220MN2PR00MB0463namp_-- From nobody Fri Jan 3 18:00:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEEA1200DB for ; Fri, 3 Jan 2020 18:00:22 -0800 (PST) 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 zawiR17rEbbg for ; Fri, 3 Jan 2020 18:00:20 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 D0C14120020 for ; Fri, 3 Jan 2020 18:00:19 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id f8so28371280vsq.8 for ; Fri, 03 Jan 2020 18:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c0LJ1SZcb6oqakm6g6iVkH9d2tF9tU9B84mNMbKT2mQ=; b=gsMXxMZv099GJCRkkgmIwTYEFBMGq3P0Xc6QkJ5PgWDoeBIsu4OywVTuOkjRczEKgi U1083TYbeG24/QxofLMOHZIDt8MURe5xfiMGMqVrCiWyjwQLPMSP9AKWN/qyVLto+s0K qUGccGLED8Pi5n3P+a9V5kkpq4KlSRS+lufI3Xomy08veUBgyu+l7X1oMwOJA1Cjuhp7 mVfND8P0mDQmnE2z76JdikP/Pi50Gj3DN2TpO7XXVMH5W/pLnRC8YQ6/LE1/cukeejk4 lFlPAMGRdxNSkCH41vLnoVvFKLjslLB0gZznM1DzRa/lQt/dXziSgl6mYgSPLQZ2tmg4 Qe0w== 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=c0LJ1SZcb6oqakm6g6iVkH9d2tF9tU9B84mNMbKT2mQ=; b=JHz4pnLzkFogm0s/1kE/VdWBOE5h+8oXZR+8xkTK/V2Ekn2Va3a+zp1sCsdCp295hP DWrBv77BpiT9h0IUEmZEvrN54IkN8qFVVBe/ENXi1ULWufDrxg14v4krFvjZhMOlEwpQ 6MizxZv7auT7t+Qlkqb8zRGCkoY9vSzdt8H76Oi7NKp56CETiirXwA3ojOgeUvptvS+L rmgqQpxQpof+GZLFhPnSCgNAy7KSsLOl6+WARFIPI2C3Z4oF1HJbycMKScC0hzvdgtIA 5O/IZHuGU+tlL26hAzqGiiPpJBgn49sUWCTRv6IDzaEP1hQJLIZz2g/U/6bjAC6VbT8D en1A== X-Gm-Message-State: APjAAAXW7o/f9FQJf4bVij5VMnB/3B0LKW5Zo/zgVgrn4HWa7/ZW4EXj gwJnkADxQbuTYOnJwOPgQKzDbcd4PxsNLi24p8E5kA== X-Google-Smtp-Source: APXvYqz0me+KO4hzusXjtV/f1r97jsgo7IIrxvNqazI09U5r/FJs93OL+bLKZdZPPhtvM98BeeK8BsRNoHkqZFOOluY= X-Received: by 2002:a67:fc09:: with SMTP id o9mr47834812vsq.75.1578103218868; Fri, 03 Jan 2020 18:00:18 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> In-Reply-To: <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> From: Brian Dickson Date: Fri, 3 Jan 2020 18:00:06 -0800 Message-ID: To: Adam Roach Cc: Jim Reid , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c79725059b46c9a0" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 04 Jan 2020 02:00:22 -0000 --000000000000c79725059b46c9a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 2, 2020 at 3:56 PM Adam Roach wrote: > [as an individual] > > On 1/2/20 5:38 PM, Jim Reid wrote: > > The debate about trust terminology/definitions is fascinating. It's very = likely to be a topic that the new WG-to-be could eventually discuss. But it= doesn't belong on this thread. Could we please branch this off somewhere e= lse so this thread can focus on the charter proposals? Thanks. > > > > Having read through this thread, I think there is a useful charter-relate= d > distinction to be made here, and I think conflating these two things may = be > one reason people are talking past each other: > > > 1. Do I trust the question I ask to be confidential? [1] > 2. Do I trust the answer I get to be accurate? > > > Given that the only context apparently under discussion is web browsers, > and given that the vast majority of HTTP connections are performed over T= LS > [2] [3], I suspect that #1 is the far more interesting question, and the > only one that really makes sense to focus on in the charter. > > > Respectfully, I disagree with this summary. Briefly: I am discussing bootstrapping into the state of having a trusted resolver (that would then be used for your HTTP stuff). It is not necessarily the case that every possible bootstrapping process can proceed without using DNSSEC. In particular, the issue generally categorized as "discovery" (but which very likely also encompasses related issues like resolver identity (name), reachability, forwarders and their topologies, and related network issues (NAT)). This is an area I am currently actively working on. Unless the WG wants to expressly reject the notion of "same resolver" as a policy for encrypted DNS (which would put Mozilla at odds with Google), I think it is premature to exclude DNSSEC validation on the client, as part of that bootstrap process. I'm reasonably confident at this point in making the following assertion: - The above dependencies are intractable. - The root problem is that private addressing and private namespaces are incompatible with CA-issued certificates, - This effectively makes TLSA records the only feasible solution for establishing TLS connections to any resolver which does not have a published public name and public (non-RFC1918) address. - TLSA (DANE) requires DNSSEC validation. Once the bootstrapping has been done, the TLS connections can be established using the trusted resolver, and depending on the browser's implementation choices, may exclude the use of DNSSEC validation. However, it is not possible to bootstrap to any resolver except those on a hardcoded list and using certificates issued by CAs from browser-specific CA sets, unless client DNSSEC validation is available. This needs to be explicitly discussed as part of the WG charter scope discussion. Brian > /a > > ____ > [1] Yes, I recognize that "confidential" raises the question "from whom," > and that the answer to that is the real underlying tension in this > discussion. I'm not trying to give that part of the question short shrift= ; > I'm eliding any such discussion because it is aggressively unrelated to m= y > point. To be clear, my point is that the *other* question is basically > uninteresting in this context. > > [2] Which makes question #2 largely irrelevant, since inaccuracies are > detected during the subsequent TLS handshake. > > [3] https://letsencrypt.org/stats/#percent-pageloads > --000000000000c79725059b46c9a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 2, 2020 at 3:56 PM Adam R= oach <adam@nostrum.com> wrote= :
=20 =20 =20
[as an individual]

On 1/2/20 5:38 PM, Jim Reid wrote:
The debate about trust terminology/definitions is fascinating. I=
t's very likely to be a topic that the new WG-to-be could eventually di=
scuss. But it doesn't belong on this thread. Could we please branch thi=
s off somewhere else so this thread can focus on the charter proposals? Tha=
nks.


Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.



Respectfully, I disag= ree with this summary.

Briefly: I am discussing bo= otstrapping into the state of having a trusted resolver (that would then be= used for your HTTP stuff).

It is not necessarily = the case that every possible bootstrapping process can proceed without usin= g DNSSEC.

In particular, the issue generally categ= orized as "discovery" (but which very likely also encompasses rel= ated issues like resolver identity (name), reachability, forwarders and the= ir topologies, and related network issues (NAT)).

= This is an area I am currently actively working on.

Unless the WG wants to expressly reject the notion of "same resolver= " as a policy for encrypted DNS (which would put Mozilla at odds with = Google), I think it is premature to exclude DNSSEC validation on the client= , as part of that bootstrap process.

I'm reaso= nably confident at this point in making the following assertion:
=
  • The above dependencies are intractable.
  • The root problem is= that private addressing and private namespaces are incompatible with CA-is= sued certificates,=C2=A0
  • This effectively makes TLSA records the on= ly feasible solution for establishing TLS connections to any resolver which= does not have a published public name and public (non-RFC1918) address.
  • TLSA (DANE) requires DNSSEC validation.
Once the = bootstrapping has been done, the TLS connections can be established=C2=A0 u= sing the trusted resolver, and depending on the browser's implementatio= n choices, may exclude the use of DNSSEC validation.

However, it is not possible to bootstrap to any resolver except those on= a hardcoded list and using certificates issued by CAs from browser-specifi= c CA sets, unless client DNSSEC validation is available.

This needs to be explicitly discussed as part of the WG charter scop= e discussion.

Brian

/a

____
[1] Yes, I recognize that "confidential" raises the questio= n "from whom," and that the answer to that is the real underlying tensio= n in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

--000000000000c79725059b46c9a0-- From nobody Fri Jan 3 20:22:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652F21200F3 for ; Fri, 3 Jan 2020 20:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uahnU5c6O1S for ; Fri, 3 Jan 2020 20:22:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E476120020 for ; Fri, 3 Jan 2020 20:22:24 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 0044MIOq010092 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Jan 2020 22:22:20 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578111740; bh=DfRijqptjpEG7HeQOA4A06m0akpM+3zOnwLw/CAjLK8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=HkdZwPwPrTqryzcPOKkrTvtrFaiXwKafqp1SxkZ9v543WKxTLjq/CbIT0lun7eYc2 8PZNnOuub73ebEsJppFnvF4yaHZ/ZHFaCiWTzzypJplYQ8wNK8OGtdwOsNiZzLh6Up qoxstKLoa2TRXCBJcyJgGjFJhNCqIswOPpWgK4fw= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Brian Dickson Cc: Jim Reid , ADD Mailing list References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> From: Adam Roach Message-ID: <49a0fbb3-5c00-bdd6-6648-477d4107c184@nostrum.com> Date: Fri, 3 Jan 2020 22:22:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 04 Jan 2020 04:22:25 -0000 On 1/3/20 8:00 PM, Brian Dickson wrote: > I think it is premature to exclude DNSSEC validation on the client, as > part of that bootstrap process. Thanks for the clarification. With your added explanation, this makes sense. To be clear, I don't agree with some of your other assertions, but you did make it clear that you're talking about DNSSEC in a very narrow, bootstrap-related capacity, and I agree that there is likely a set of solutions that lie down that path. I think we can come up with better solutions than the one you sketched out, but I agree with you that the charter should not rule it out of scope. /a From nobody Sat Jan 4 08:20:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7B212007C for ; Sat, 4 Jan 2020 08:20:45 -0800 (PST) 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=unavailable 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 htPsprPEFl9B for ; Sat, 4 Jan 2020 08:20:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E62120046 for ; Sat, 4 Jan 2020 08:20:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B8AFBE50; Sat, 4 Jan 2020 16:20:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVF442BlJnWe; Sat, 4 Jan 2020 16:20:37 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 02CE3BE2F; Sat, 4 Jan 2020 16:20:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578154837; bh=4J4p5ZiRnw0vqSwW/J5YEYBlykcFpguxv6DTe6cujnE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=pyvInYlBtebo2xyzwQ5aREGuqyir1P9+DTGn8qG4rpjX0E9tvAXWLhk6AVGmAhXX+ /+VIcJtZC130UHidUpf2SeoRUnP5+tXEXFAH71PQUnKUH3TZi/tcrOoT0t0OLk5a6q 0XmUePTqL+dMtsTU6flyEw2JXjuR/cZUacOJ+XfA= To: Ben Schwartz , ADD Mailing list References: From: Stephen Farrell 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: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> Date: Sat, 4 Jan 2020 16:20:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="23Hffe7d7xBKV1FGjwYPnLD6AEHklzneN" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 04 Jan 2020 16:20:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --23Hffe7d7xBKV1FGjwYPnLD6AEHklzneN Content-Type: multipart/mixed; boundary="32swhEpu2n4qVLo49xdCx0w0yAapvVZr2"; protected-headers="v1" From: Stephen Farrell To: Ben Schwartz , ADD Mailing list Message-ID: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> Subject: Re: [Add] A proposed charter for ABCD References: In-Reply-To: --32swhEpu2n4qVLo49xdCx0w0yAapvVZr2 Content-Type: multipart/mixed; boundary="------------DF699456FF6CBF4CBDBCF8C8" Content-Language: en-US This is a multi-part message in MIME format. --------------DF699456FF6CBF4CBDBCF8C8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, The verbosity and lack of agreement and clarity on the list since this was posted has convinced me that this is not a viable charter. That said, some (mostly negative, sorry;-) comments below... Cheers, S. On 20/12/2019 15:20, Ben Schwartz wrote: > Hello ADD list, >=20 > Based on the feedback from the ABCD BoF at IETF 106, and with additiona= l > input from chairs and area directors from relevant working groups, the = ABCD > BoF chairs have drafted the following updated charter for a working gro= up. > Please review it and share your perspective. >=20 > Tommy Pauly has recently posted a charter text proposal that considers > closely related issues. This is not a competition, so please avoid =E2=80= =9Cvoting=E2=80=9D > for one proposed text over the other. The text of any final charter wi= ll > be written by the IESG. To help them judge whether a working group sho= uld > be formed, and how it should be chartered, the most productive input wo= uld > be to know which elements of each text you find valuable (if any), and > which you would like to see changed in any final charter. Tommy's proposal has the benefit of covering fewer topics. I think that's (fewer topics) likely a requirement if any progress is to be made. >=20 > ----------------------------------- >=20 > Proposed charter text: >=20 > This working group will focus on DNS client side topics, particularly > discovery and selection of resolvers. This complements existing DNS-rel= ated > working groups, which are responsible for improvements to the DNS proto= col > itself, and for operational questions that are principally of interest = to > DNS server operators. I like that you've tried to provide a logical functional basis for what to in/exclude in the WG. However, my take is that success/failure will be much more driven by the non-functional aspects (e.g. cat-herding, not biting off more than can be chewed) so I'm not sure this is needed, even if it's clever;-) >=20 > The working group is chartered to develop an extensible protocol for a = DNS > client to learn detailed information about a resolver, based on > draft-ietf-dnsop-resolver-information, which will be transferred from > dnsop. Using that to discover that a recursive offers DoT/DoH seems to provide, at best, opportunistic security. But I like opportunistic security approaches, where they're useful, and it could be useful here, in some networks. In other networks and for some applications, the OS approach will provide no substantive benefit. For opportunistic security to be useful also needs at least a story/plan for how to get to something better. So I think there's a major missing part here about re-visited networks. (Even if aspects of that are implementation-specific, the story is needed before we know the opportunistic staging post is useful.) I think a wg that doesn't start out with an agreed understanding as to whether or not discovery being opportunistic is ok or not will fail. There may even be a need to catalog the various possible setups and how discovery plays out in each in order to make progress. (Recent list discussion with unqualified uses of the term "trust" along with ambiguous pronouns seems to indicate that may be needed.) Even with all that, I'm not clear what'd motivate an application (whether a browser or something else) to want to do this, though I can see this possibly being useful for a system or OS stub. I could also see some applications using this as a way to be seen to be "doing something." All that said, the "useful" here doesn't seem like a huge win really in many networks. (IOW, if someone thinks defining this will stop applications using their own choices of DoH server, my guess is that that's wishful thinking.) I don't understand the information leakage aspects of this, if a non-updated recursive forwards the queries upward, nor potential attacks (on stubs, launched by/via recursives) this might enable. (E.g. does the nxdomain for the first a.b.c.10.in-addr.arpa mean no other e.f.g.10.in-addr.arpa will be forwarded for the TTL?) I'm not convinced this putative wg is the right place to develop an extensible protocol like this - dnsop seems much better suited really, so I'd argue to leave that draft in dnsop. > Relying on this new protocol where appropriate, the working group > should produce standards-track, informational, or experimental document= s > that provide the following items, using the drafts in brackets as input= > (with no obligation to adopt them): > * methods for a recursive resolver to advertise support for an alterna= tive > transport protocol [draft-sah-resinfo-doh], The security considerations of that seem to me to make it either pointless (already doing DoT/DoH) or impossible (DNSSEC for 10.in-addr.arpa). > * methods for a recursive resolver to indicate that it will sometimes > return DNS results that are different from the global DNS > [draft-grover-add-policy-detection], That bit seems ok, though canaries are fragile of course. It's not clear to me that needs to be in the same WG as the recursive discovery bits, but it could be. I don't get why both TBD.arpa and .arpa would need to be supported by recursive developers. ISTM one kind of oddball qname for this stuff ought suffice for all of the things envisaged in these drafts. > * methods for improving user privacy by avoiding DNS queries that leak= > information or directing them to a server that will have this informati= on > anyway [draft-pauly-dprive-adaptive-dns-privacy], and I think that draft by itself (and what it implies) is already the meat for an ambitious WG. > * a format for describing the client=E2=80=99s DNS configuration, suit= able for > diagnostics and debugging. I'm not clear why this is needed. Attempting all of the above is IMO way too ambitious given the divergent interests and trust models visible in folks postings to this list over the last 8 months. >=20 > Where possible, any mechanisms that specify exchange of information bet= ween > clients and resolvers should provide the security properties expected o= f > IETF protocols, e.g., confidentiality protection, integrity protection,= and > authentication with strong work factor. Each specification must clearl= y > indicate under what circumstances and assumptions these properties are = or > are not provided. I'm not sure why including that boilerplate-like text is a good idea. > This working group will coordinate and share WGLC announcements with th= e > following working groups: dnsop, capport, dprive, dhc, and homenet. The= > working group will also coordinate with the Security Area, and will be > assigned a security advisor. Assigned security advisors aren't that useful I think. The person concerned is either interested or not, if they are they'll not be shy. If they're not, they'll not be useful. >=20 > P.S. One note regarding this proposal: the chairs of the doh working gr= oup > expect that doh would be closed if a new working group were chartered i= n > this manner or similar. >=20 >=20 --------------DF699456FF6CBF4CBDBCF8C8 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----- --------------DF699456FF6CBF4CBDBCF8C8-- --32swhEpu2n4qVLo49xdCx0w0yAapvVZr2-- --23Hffe7d7xBKV1FGjwYPnLD6AEHklzneN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4Qu1MACgkQWrL68XsX K+qYyQ//XTQY34ZvlEdobl/foRc0Vx1i0zV7mLN1XbCdTK/QkU2qmWgQ1dgk/PZD dobfy5F5mgdoZ73+1W5HUJfCdg7DzJvxWsgoHxTXteLlCd2ZT3lkmf8SsFavJNLo luUjbaVqobt4PjRKNXdrO/Mt4tE2JMjnslvqH4tSxUBmdpPYd2uPubmuRVdua9n1 gB7K7TP9wTcU7PTvZvajqagWQXa8+akb5A+t0K1J2wAPD+hHbOSHfDE0SbEvpD5h +Vd2zfM7bQCvlkXK08/qov6dgm3vdHLDtyRaN2REubGBBiyiAqns0xaaOngoMmf/ 5ARxQhDEhJujcaScU/E1LfFcldFz5bVzV1AxM7rzy/rmfuvJAGtOYhPSBcEH3gEe 7k7wyNAXVABrH4r6m0xhnO41itrCQoWT/p/H7MG7KW+U7CxfhOm0yG2dRfqvZLXM VASrv/kgzj/QEzGl+H3RDG2LV8UJyzCYD4LsnRSdWyjkcSapAIejQe3kSi/EQVen 34kwvSu+s8QFtm6aXQGA35r59ANGq6hKXfBTwgonjT4C3MIUNlkRIRDpqnz2PadB DRoqEi9pdjKdDQLYxTcp9qMrB3flhqTw8n+C8f5oJO7UjGOLvoFjCPGPJ0EXYYm0 XxuL61wG2jV/v5UXAYy2+Pt1DIUhfO5ILlmVM0u1cv5kDSzpnjI= =yjDA -----END PGP SIGNATURE----- --23Hffe7d7xBKV1FGjwYPnLD6AEHklzneN-- From nobody Sat Jan 4 13:28:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936C312002F for ; Sat, 4 Jan 2020 13:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlWWBU_6nJ41 for ; Sat, 4 Jan 2020 13:28:25 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 A2318120013 for ; Sat, 4 Jan 2020 13:28:24 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id f15so34002845lfl.13 for ; Sat, 04 Jan 2020 13:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=brZTI2jp3EWLPFgSjshG4fznx/Lh4HBz+I4egZNqVvU=; b=B6Ay5+SnYrj+SdgJL3/ECOV+C/mQNgwQ2vjlKzQV4yefLF511LeFkkdbULnB41d5DN BA1ZKxewX1zg6a2Mw7ayFkX7ULdGHQ/cS5iroOsMAT84ZUjoONMhhglpTMNBl2YXH9j3 a6aCJfRh3M6/zBFx279/grFIaObtdL5strkOr2sSkKJQCXSf/ymxbhm7gopBuJJ8hyd7 +Y/VKiH5yKvZrEfLCL4eaXXNSklWokZZGPBl+tJH1e5dNmUSImeTZ4pMEugr9VuRIcmo ZFrmemSf8o8JqvuKtVMhExvORNDkCBXB3WrsjXTRzEE0q5jAqaqxQ1KYeeIirQGJ+bIJ HtqA== 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=brZTI2jp3EWLPFgSjshG4fznx/Lh4HBz+I4egZNqVvU=; b=VHCqSAipEKizyJOFPvqgQdB+ugu5anQL+jMGHgJhoXWawgZR810DDqsmceaqdzK7WU al+VloosWsLqibyBHEogROvyWiY7vhAXU7eaijvjH6qvc7FGUIjWlQyU52vw7WPLZUjo qIpmJJr8B2kJgEgzcot5qmbpirKAHiRKNBp/frOzk4HbaGtZLYE1zE5YYs97NhVTTn1s ueHYPj2qry/X6aB9NZR5lXi3eeyn3Zpf97JcVspg+pCA9g5+bwyymfMJA1vfhw14ZzIQ 1GV9ci0qH9ZQwgCK+G9d0zn8rAk3TRcvVw2kaQHmEQ5PsbLHNkrBVOQcmJEAVF2E9hSC xldg== X-Gm-Message-State: APjAAAVnUHwK+B1Ocm2PWueloRHADDelg57b1Rm5Kv+1bma5wxuKjQZb +7SXPY8mdGE9D1tI1BMWI7rpOLA3fXbGh6MsAHJZsA== X-Google-Smtp-Source: APXvYqytR7xhjS2+hZ78NTYuURZUe9kuyhu1d1/uAq4U7XDDxeeu/8PSVdaZyhw1a2QDviS7lFKtNYGSiffUcmcQGW8= X-Received: by 2002:a19:7701:: with SMTP id s1mr53178491lfc.180.1578173302857; Sat, 04 Jan 2020 13:28:22 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Sat, 4 Jan 2020 13:27:46 -0800 Message-ID: To: Brian Dickson Cc: Adam Roach , Jim Reid , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000001c7433059b571b65" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 04 Jan 2020 21:28:27 -0000 --0000000000001c7433059b571b65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson wrote: > > > On Thu, Jan 2, 2020 at 3:56 PM Adam Roach wrote: > >> [as an individual] >> >> On 1/2/20 5:38 PM, Jim Reid wrote: >> >> The debate about trust terminology/definitions is fascinating. It's very= likely to be a topic that the new WG-to-be could eventually discuss. But i= t doesn't belong on this thread. Could we please branch this off somewhere = else so this thread can focus on the charter proposals? Thanks. >> >> >> >> Having read through this thread, I think there is a useful >> charter-related distinction to be made here, and I think conflating thes= e >> two things may be one reason people are talking past each other: >> >> >> 1. Do I trust the question I ask to be confidential? [1] >> 2. Do I trust the answer I get to be accurate? >> >> >> Given that the only context apparently under discussion is web browsers, >> and given that the vast majority of HTTP connections are performed over = TLS >> [2] [3], I suspect that #1 is the far more interesting question, and the >> only one that really makes sense to focus on in the charter. >> >> >> > Respectfully, I disagree with this summary. > > Briefly: I am discussing bootstrapping into the state of having a trusted > resolver (that would then be used for your HTTP stuff). > > It is not necessarily the case that every possible bootstrapping process > can proceed without using DNSSEC. > > In particular, the issue generally categorized as "discovery" (but which > very likely also encompasses related issues like resolver identity (name)= , > reachability, forwarders and their topologies, and related network issues > (NAT)). > > This is an area I am currently actively working on. > > Unless the WG wants to expressly reject the notion of "same resolver" as = a > policy for encrypted DNS (which would put Mozilla at odds with Google), I > think it is premature to exclude DNSSEC validation on the client, as part > of that bootstrap process. > It might be helpful if you laid out what role you think cryptographic authentication is playing here. Cryptographic authentication, whether via WebPKI or DNSSEC/TLSA, ties the server to a given identity. So, the first step is to ask where that identity comes from and why you trust *that*. So perhaps you could start by laying out the setting you have in mind. -Ekr > > I'm reasonably confident at this point in making the following assertion: > > - The above dependencies are intractable. > - The root problem is that private addressing and private namespaces > are incompatible with CA-issued certificates, > - This effectively makes TLSA records the only feasible solution for > establishing TLS connections to any resolver which does not have a > published public name and public (non-RFC1918) address. > - TLSA (DANE) requires DNSSEC validation. > > Once the bootstrapping has been done, the TLS connections can be > established using the trusted resolver, and depending on the browser's > implementation choices, may exclude the use of DNSSEC validation. > > However, it is not possible to bootstrap to any resolver except those on = a > hardcoded list and using certificates issued by CAs from browser-specific > CA sets, unless client DNSSEC validation is available. > > This needs to be explicitly discussed as part of the WG charter scope > discussion. > > Brian > >> /a >> >> ____ >> [1] Yes, I recognize that "confidential" raises the question "from whom,= " >> and that the answer to that is the real underlying tension in this >> discussion. I'm not trying to give that part of the question short shrif= t; >> I'm eliding any such discussion because it is aggressively unrelated to = my >> point. To be clear, my point is that the *other* question is basically >> uninteresting in this context. >> >> [2] Which makes question #2 largely irrelevant, since inaccuracies are >> detected during the subsequent TLS handshake. >> >> [3] https://letsencrypt.org/stats/#percent-pageloads >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000001c7433059b571b65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 3, 2020 at 6:00 PM Brian = Dickson <brian.peter.di= ckson@gmail.com> wrote:


On Thu, Jan 2, 2020 = at 3:56 PM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
[as an individual]

On 1/2/20 5:38 PM, Jim Reid wrote:
The debate about trust terminology/definitions is fascinating. I=
t's very likely to be a topic that the new WG-to-be could eventually di=
scuss. But it doesn't belong on this thread. Could we please branch thi=
s off somewhere else so this thread can focus on the charter proposals? Tha=
nks.


Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.



Respectfully, I disag= ree with this summary.

Briefly: I am discussing bo= otstrapping into the state of having a trusted resolver (that would then be= used for your HTTP stuff).

It is not necessarily = the case that every possible bootstrapping process can proceed without usin= g DNSSEC.

In particular, the issue generally categ= orized as "discovery" (but which very likely also encompasses rel= ated issues like resolver identity (name), reachability, forwarders and the= ir topologies, and related network issues (NAT)).

= This is an area I am currently actively working on.

Unless the WG wants to expressly reject the notion of "same resolver= " as a policy for encrypted DNS (which would put Mozilla at odds with = Google), I think it is premature to exclude DNSSEC validation on the client= , as part of that bootstrap process.
It might be helpful if you laid out what role you think cryptog= raphic
authentication is playing here.

Cryptographic authenticati= on, whether via WebPKI or DNSSEC/TLSA, ties
the server to a given identi= ty. So, the first step is to ask where
that identity comes from and why = you trust *that*. So perhaps you
could start by laying out the setting y= ou have in mind.

-Ekr
=C2=A0

I'm reasonably confident at this point in making the following = assertion:
  • The above dependencies are intractable.
    • The root problem is that private addressing and private namespaces are in= compatible with CA-issued certificates,=C2=A0
  • This effectively make= s TLSA records the only feasible solution for establishing TLS connections = to any resolver which does not have a published public name and public (non= -RFC1918) address.
  • TLSA (DANE) requires DNSSEC validation.
Once the bootstrapping has been done, the TLS connections can b= e established=C2=A0 using the trusted resolver, and depending on the browse= r's implementation choices, may exclude the use of DNSSEC validation.

However, it is not possible to bootstrap to any res= olver except those on a hardcoded list and using certificates issued by CAs= from browser-specific CA sets, unless client DNSSEC validation is availabl= e.

This needs to be explicitly discussed as part o= f the WG charter scope discussion.

Brian

/a

____
[1] Yes, I recognize that "confidential" raises the questio= n "from whom," and that the answer to that is the real underlying tensio= n in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000001c7433059b571b65-- From nobody Sat Jan 4 15:37:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191461200A1 for ; Sat, 4 Jan 2020 15:37:52 -0800 (PST) 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 rK5zynwfTOGJ for ; Sat, 4 Jan 2020 15:37:49 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 E8955120071 for ; Sat, 4 Jan 2020 15:37:48 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id l6so15876394uap.13 for ; Sat, 04 Jan 2020 15:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lcTOMblAdhQEBEeetb5rDXvLtjNJe3WmVnKeSHrxTNY=; b=ZG915+B7oGxQ9kzqFQcuc7XMVJxgCret8Sc02vGOTE+lzhHTM72XyrnFsXOx4bJLUN s7tp9esEraSwu0Xu7RiiwLPs+bBVh6FlgI/RMQ8hTFfAGg7l5YthmGaCeZF/TjHfbvvK VpB13DzaLlkB7NUQ81RCYBCtNIi19vNJejniz0aQb9w4IabRbGDfbO8VAguOQeWw9G5G KbKkIs+WMjiS6oO6e5r8CTbb85/knyI9JHXCvAjJE9OC1kmXd2g5VtaNTpF59H8xuRtp pRjP+i9BjC/z6/A9A9x7WVFtI7t2lfNts5j9IiY+PbR8YnIujIz0CVgKDfo1rwRXi8vA w6xw== 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=lcTOMblAdhQEBEeetb5rDXvLtjNJe3WmVnKeSHrxTNY=; b=nVmJvF0Iv+Osv4vWufLX6CLvrzf9rWv8Mn59ZSxCbp8TklpKq0oqlBaAFVMGHK/LEk vqnWyuPXI7qRiPHPith1o75MUphkEGUSZLk2LrZF2SRfpdsh9+jgVe1EpHk0w9QPaSSq zcL5jqaPA/TskJfjFYrB97OSNr0gpFVozLTLa5/9LsXDfB6fw78Py3ufbI4MqsbIk3is rHeRbdy/3h/W+n3L12Vou97sJdN39k3zxDCkJso2koRdq6/YhMu8+UJqCiGUXYy/5h2P 5Wj4rhmIG1m2wL53odrULbDzwGCbYIUUfUJVEcUI2hIyII850gHrbSv1sSM7q9sj/WPW KW5Q== X-Gm-Message-State: APjAAAXqKPEXjZ4NnSLzMbHlImfv112rSqz8BDJ/3LE2AtwK3d3MjXTL y7wTA14C0NVBCNA1aIg5SgJxK10Y41rWhD44Kjw= X-Google-Smtp-Source: APXvYqwxE9Tfdcqbp2LUXVXQj3kzmfxMT5/pqarIZ35rvLGbCMIfNMZq+QsDtSdJwEL7Vf0KORe0biZ7Za3Z/gZqdZg= X-Received: by 2002:ab0:634c:: with SMTP id f12mr51406667uap.48.1578181067985; Sat, 04 Jan 2020 15:37:47 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> In-Reply-To: From: Brian Dickson Date: Sat, 4 Jan 2020 15:37:36 -0800 Message-ID: To: Eric Rescorla Cc: Adam Roach , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f2d7e3059b58e956" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 04 Jan 2020 23:37:52 -0000 --000000000000f2d7e3059b58e956 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 4, 2020 at 1:28 PM Eric Rescorla wrote: > > > On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> >> On Thu, Jan 2, 2020 at 3:56 PM Adam Roach wrote: >> >>> [as an individual] >>> >>> On 1/2/20 5:38 PM, Jim Reid wrote: >>> >>> The debate about trust terminology/definitions is fascinating. It's ver= y likely to be a topic that the new WG-to-be could eventually discuss. But = it doesn't belong on this thread. Could we please branch this off somewhere= else so this thread can focus on the charter proposals? Thanks. >>> >>> >>> >>> Having read through this thread, I think there is a useful >>> charter-related distinction to be made here, and I think conflating the= se >>> two things may be one reason people are talking past each other: >>> >>> >>> 1. Do I trust the question I ask to be confidential? [1] >>> 2. Do I trust the answer I get to be accurate? >>> >>> >>> Given that the only context apparently under discussion is web browsers= , >>> and given that the vast majority of HTTP connections are performed over= TLS >>> [2] [3], I suspect that #1 is the far more interesting question, and th= e >>> only one that really makes sense to focus on in the charter. >>> >>> >>> >> Respectfully, I disagree with this summary. >> >> Briefly: I am discussing bootstrapping into the state of having a truste= d >> resolver (that would then be used for your HTTP stuff). >> >> It is not necessarily the case that every possible bootstrapping process >> can proceed without using DNSSEC. >> >> In particular, the issue generally categorized as "discovery" (but which >> very likely also encompasses related issues like resolver identity (name= ), >> reachability, forwarders and their topologies, and related network issue= s >> (NAT)). >> >> This is an area I am currently actively working on. >> >> Unless the WG wants to expressly reject the notion of "same resolver" as >> a policy for encrypted DNS (which would put Mozilla at odds with Google)= , I >> think it is premature to exclude DNSSEC validation on the client, as par= t >> of that bootstrap process. >> > > It might be helpful if you laid out what role you think cryptographic > authentication is playing here. > > Cryptographic authentication, whether via WebPKI or DNSSEC/TLSA, ties > the server to a given identity. So, the first step is to ask where > that identity comes from and why you trust *that*. So perhaps you > could start by laying out the setting you have in mind. > The specifics are part of the stuff I'm working on currently (doing a proof of concept), but at a 50,000 foot level: - The identity is generated by the server itself, and has a corresponding DNS zone which is locally scoped (won't work outside the local environment, for some value of "local), but globally unique. Makin= g the name a zone allows all the data to be DNSSEC signed and relies only = on a single trust anchor specific to the server (the DNSKEY with SEP bit se= t for the zone itself). - The trust for that requires some mechanism for distributing the corresponding trust anchor. - Maybe technically out of scope for the WG but definitely a requirement to bootstrap securely. Potential methods might include: - DHCP - dot1x, or something similar - unique-per-client name (but perhaps sharing a public key?) - some demonstration that DHCP spoofing or RA spoofing is not possible in the local environment (e.g. dot1x for port access, and us= ing DHCP for obtaining the DNSKEY) - Publication via other non-networked mechanisms, e.g. with QR codes (under physical control of the operator), for example - coffee shop paper slips with a QR code rather than just an SSID, username, password (which don't prevent SSID spoofing) - CCTV channels (hotels, conference display panels, etc) with QR codes, or menus with QR codes. - QR code published on a TLS-protected web site (e.g. conference web site), available before traveling or on-site - QR code on badges - QR code on T-Shirts etc - The QR code would need to encode the public key and name, and would prevent spoofing since only the actual server would have the necessar= y private key with which to sign the data. - The trust of such a QR code and corresponding server is possibly subjective, but at least under the control of whoever controls the lo= cal "meat-space" - Advanced ideas could include things like rotating names and keys, sync'd via a seed, on a physical (hardened) token with a display for = a QR code. The identity, being local in scope, can be changed as frequently as necessary, potentially extremely frequently (every 15 minutes?). Having a naming scheme with enough entropy is sufficient to prevent collision and prevent guessing, thus making it more secure and/or more trustworthy (I think). Eg. 12-characters of [LD] gives 36^12 combinations, or 4e21 or thereabouts. Want more entropy? Add more characters. The base-36 exponential curve gets very big, very fast. Making it machine-readable or published electronically removes the UI/UX element from consideration. The locally significant aspect would be to place it in an unused and un-assignable namespace, e.g. the ISO reserved 2-letter codes that were discussed in DPRIVE or DNSOP (such as zz pseudo-TLD). The TLS aspect would generally require self-signed certs with TLSA type 3-1-1 records published (EE public key fingerprint) for validation, and would be in a 1:1 lock-step with the identity (and zone name). Assuming the POC works, I think most of the above aspects can be reduced to bike-shedding. Brian > > -Ekr > > >> >> I'm reasonably confident at this point in making the following assertion= : >> >> - The above dependencies are intractable. >> - The root problem is that private addressing and private namespaces >> are incompatible with CA-issued certificates, >> - This effectively makes TLSA records the only feasible solution for >> establishing TLS connections to any resolver which does not have a >> published public name and public (non-RFC1918) address. >> - TLSA (DANE) requires DNSSEC validation. >> >> Once the bootstrapping has been done, the TLS connections can be >> established using the trusted resolver, and depending on the browser's >> implementation choices, may exclude the use of DNSSEC validation. >> >> However, it is not possible to bootstrap to any resolver except those on >> a hardcoded list and using certificates issued by CAs from browser-speci= fic >> CA sets, unless client DNSSEC validation is available. >> >> This needs to be explicitly discussed as part of the WG charter scope >> discussion. >> >> Brian >> >>> /a >>> >>> ____ >>> [1] Yes, I recognize that "confidential" raises the question "from >>> whom," and that the answer to that is the real underlying tension in th= is >>> discussion. I'm not trying to give that part of the question short shri= ft; >>> I'm eliding any such discussion because it is aggressively unrelated to= my >>> point. To be clear, my point is that the *other* question is basically >>> uninteresting in this context. >>> >>> [2] Which makes question #2 largely irrelevant, since inaccuracies are >>> detected during the subsequent TLS handshake. >>> >>> [3] https://letsencrypt.org/stats/#percent-pageloads >>> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > --000000000000f2d7e3059b58e956 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 4, 2020 at 1:28 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson <brian.peter.dic= kson@gmail.com> wrote:


On Thu, Jan 2, 2020 at = 3:56 PM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
[as an individual]

On 1/2/20 5:38 PM, Jim Reid wrote:
The debate about trust terminology/definitions is fascinating. I=
t's very likely to be a topic that the new WG-to-be could eventually di=
scuss. But it doesn't belong on this thread. Could we please branch thi=
s off somewhere else so this thread can focus on the charter proposals? Tha=
nks.


Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.



Respectfully, I disag= ree with this summary.

Briefly: I am discussing bo= otstrapping into the state of having a trusted resolver (that would then be= used for your HTTP stuff).

It is not necessarily = the case that every possible bootstrapping process can proceed without usin= g DNSSEC.

In particular, the issue generally categ= orized as "discovery" (but which very likely also encompasses rel= ated issues like resolver identity (name), reachability, forwarders and the= ir topologies, and related network issues (NAT)).

= This is an area I am currently actively working on.

Unless the WG wants to expressly reject the notion of "same resolver= " as a policy for encrypted DNS (which would put Mozilla at odds with = Google), I think it is premature to exclude DNSSEC validation on the client= , as part of that bootstrap process.
It might be helpful if you laid out what role you think cryptog= raphic
authentication is playing here.

Cryptographic authenticati= on, whether via WebPKI or DNSSEC/TLSA, ties
the server to a given identi= ty. So, the first step is to ask where
that identity comes from and why = you trust *that*. So perhaps you
could start by laying out the setting y= ou have in mind.

The = specifics are part of the stuff I'm working on currently (doing a proof= of concept), but at a 50,000 foot level:
  • The identity is= generated by the server itself, and has a corresponding DNS zone which is = locally scoped (won't work outside the local environment, for some valu= e of "local), but globally unique. Making the name a zone allows all t= he data to be DNSSEC signed and relies only on a single trust anchor specif= ic to the server (the DNSKEY with SEP bit set for the zone itself).
    • The trust for that requires some mechanism for distributing the correspond= ing trust anchor.=C2=A0
  • Maybe technically out o= f scope for the WG but definitely a requirement to bootstrap securely. Pote= ntial methods might include:
    • DHCP
    • dot1x, or something s= imilar
    • unique-per-client name (but perhaps sharing a public key?)
    • some demonstration that DHCP spoofing or RA spoofing is not possible= in the local environment (e.g. dot1x for port access, and using DHCP for o= btaining the DNSKEY)
    • Publication via other non-networked mechanisms= , e.g. with QR codes (under physical control of the operator), for example<= /li>
      • coffee shop paper slips with a QR code rather than just an SSID= , username, password (which don't prevent SSID spoofing)
      • CCTV c= hannels (hotels, conference display panels, etc) with QR codes, or menus wi= th QR codes.=C2=A0
      • QR code published on a TLS-protected web site (e= .g. conference web site), available before traveling or on-site
      • QR = code on badges
      • QR code on T-Shirts etc
    • The QR code wou= ld need to encode the public key and name, and would prevent spoofing since= only the actual server would have the necessary private key with which to = sign the data.
    • The trust of such a QR code and corresponding server= is possibly subjective, but at least under the control of whoever controls= the local "meat-space"
    • Advanced ideas could include thin= gs like rotating names and keys, sync'd via a seed, on a physical (hard= ened) token with a display for a QR code.
The iden= tity, being local in scope, can be changed as frequently as necessary, pote= ntially extremely frequently (every 15 minutes?).
Having a naming= scheme with enough entropy is sufficient to prevent collision and prevent = guessing, thus making it more secure and/or more trustworthy (I think).=C2= =A0

Eg. 12-characters of [LD] gives 36^12 combinat= ions, or 4e21 or thereabouts. Want more entropy? Add more characters. The b= ase-36 exponential curve gets very big, very fast. Making it machine-readab= le or published electronically removes the UI/UX element from consideration= .

The locally significant aspect would be to place= it in an unused and un-assignable namespace, e.g. the ISO reserved 2-lette= r codes that were discussed in DPRIVE or DNSOP (such as zz pseudo-TLD).

The TLS aspect would generally require self-signed ce= rts with TLSA type 3-1-1 records published (EE public key fingerprint) for = validation, and would be in a 1:1 lock-step with the identity (and zone nam= e).

Assuming the POC works, I think most of the ab= ove aspects can be reduced to bike-shedding.

Brian=
=C2=A0

-Ekr
=C2=A0

I'm reasonably confident at this p= oint in making the following assertion:
  • The above depende= ncies are intractable.
  • The root problem is that private addressing = and private namespaces are incompatible with CA-issued certificates,=C2=A0<= /li>
  • This effectively makes TLSA records the only feasible solution for = establishing TLS connections to any resolver which does not have a publishe= d public name and public (non-RFC1918) address.
  • TLSA (DANE) require= s DNSSEC validation.
Once the bootstrapping has been do= ne, the TLS connections can be established=C2=A0 using the trusted resolver= , and depending on the browser's implementation choices, may exclude th= e use of DNSSEC validation.

However, it is not pos= sible to bootstrap to any resolver except those on a hardcoded list and usi= ng certificates issued by CAs from browser-specific CA sets, unless client = DNSSEC validation is available.

This needs to be e= xplicitly discussed as part of the WG charter scope discussion.
<= br>
Brian
=

/a

____
[1] Yes, I recognize that "confidential" raises the questio= n "from whom," and that the answer to that is the real underlying tensio= n in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000f2d7e3059b58e956-- From nobody Sat Jan 4 16:01:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D03F12008F for ; Sat, 4 Jan 2020 16:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJVaEpiA9p5u for ; Sat, 4 Jan 2020 16:01:48 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 65B81120071 for ; Sat, 4 Jan 2020 16:01:47 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id u71so47324144lje.11 for ; Sat, 04 Jan 2020 16:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ad0a/2skQNU/eIX+d5uzv3LppJ/5vSOBXBJY47WL2Rs=; b=c3Vgu7Fv2KPkuxPSzjGS4DByAF0dw46gcv04jgqceu0jYJ3tHcIaMFi2D3s+plqWEP YE9rqm1Nrc2Zr2Zan0eETDGOO16tvBJ42n6PHKM21DHLd0Kfd6/YggfKrD70gXq/Bwsw aKaSeHQe+w1Hnt17BfZ+rP3lXXcqpeqQBSUOZPQ1x/Gkipf/JMVgz8BluHAiysmlJaxC lmIRLRQpcsxScIIw1ifYs52dX5VE47ymmmO5dVMbBrjebRNKBlFUGaGTrGFg87KAUYh9 wPmibdseCPwC/4voZ5iiJLpLS3fDO/+UsF1WPXspr5w9OyeDjk0Fg7A57HwhfqzpTbbN wE8A== 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=ad0a/2skQNU/eIX+d5uzv3LppJ/5vSOBXBJY47WL2Rs=; b=G6r6O5qOy5IKXIeXr8lDorhFiq88ym3WKaPdbC2sOTEKi4rohYxk6AMvLqpEr50BjZ HrdhojieQz96k5AAKj4MmI52AgfsdQpjgZihuLaPS1lm7pYsz/wnVfgghpwN/3Or68FK jvvcLJjPka/rDdOHFgnF+e//prXLNc+y+0N9oECeR4h6tOXGD11G4WVibddO2Fyt/JKA DHsSm5IgXFSnyM9pwDj5D6oW+12BiVypDdD/ErhHrP7xxWN9JDd2xvkcWY8N9BLHLmfT weuZG/rBmG40gzmUtmTa0J11nCXrsDqMVq2fg8KpZ8PrAePtlgzksXYrrDNKBvpiqyp4 uOZQ== X-Gm-Message-State: APjAAAVFLzQ99RgmWGsLqxclTxguiWEm/4zZgCxow9n80udCDbFK677D ES6d8KFaFdlL5CvlVQnYH95HQ9SMG3NxYpVWo/FtFw== X-Google-Smtp-Source: APXvYqxHWnOhjEoh7X32wz2VyhvfyF4Cux5E/lPmlbnWBX0UohY/Lt4CNof67jnQFWvl5r4KldilS4Z422Zxlx78sdQ= X-Received: by 2002:a2e:870b:: with SMTP id m11mr54751706lji.93.1578182505620; Sat, 04 Jan 2020 16:01:45 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Sat, 4 Jan 2020 16:01:09 -0800 Message-ID: To: Brian Dickson Cc: Adam Roach , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a37cbf059b593fef" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 00:01:51 -0000 --000000000000a37cbf059b593fef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 4, 2020 at 3:37 PM Brian Dickson wrote: > > > On Sat, Jan 4, 2020 at 1:28 PM Eric Rescorla wrote: > >> >> >> On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson < >> brian.peter.dickson@gmail.com> wrote: >> >>> >>> >>> On Thu, Jan 2, 2020 at 3:56 PM Adam Roach wrote: >>> >>>> [as an individual] >>>> >>>> On 1/2/20 5:38 PM, Jim Reid wrote: >>>> >>>> The debate about trust terminology/definitions is fascinating. It's ve= ry likely to be a topic that the new WG-to-be could eventually discuss. But= it doesn't belong on this thread. Could we please branch this off somewher= e else so this thread can focus on the charter proposals? Thanks. >>>> >>>> >>>> >>>> Having read through this thread, I think there is a useful >>>> charter-related distinction to be made here, and I think conflating th= ese >>>> two things may be one reason people are talking past each other: >>>> >>>> >>>> 1. Do I trust the question I ask to be confidential? [1] >>>> 2. Do I trust the answer I get to be accurate? >>>> >>>> >>>> Given that the only context apparently under discussion is web >>>> browsers, and given that the vast majority of HTTP connections are >>>> performed over TLS [2] [3], I suspect that #1 is the far more interest= ing >>>> question, and the only one that really makes sense to focus on in the >>>> charter. >>>> >>>> >>>> >>> Respectfully, I disagree with this summary. >>> >>> Briefly: I am discussing bootstrapping into the state of having a >>> trusted resolver (that would then be used for your HTTP stuff). >>> >>> It is not necessarily the case that every possible bootstrapping proces= s >>> can proceed without using DNSSEC. >>> >>> In particular, the issue generally categorized as "discovery" (but whic= h >>> very likely also encompasses related issues like resolver identity (nam= e), >>> reachability, forwarders and their topologies, and related network issu= es >>> (NAT)). >>> >>> This is an area I am currently actively working on. >>> >>> Unless the WG wants to expressly reject the notion of "same resolver" a= s >>> a policy for encrypted DNS (which would put Mozilla at odds with Google= ), I >>> think it is premature to exclude DNSSEC validation on the client, as pa= rt >>> of that bootstrap process. >>> >> >> It might be helpful if you laid out what role you think cryptographic >> authentication is playing here. >> >> Cryptographic authentication, whether via WebPKI or DNSSEC/TLSA, ties >> the server to a given identity. So, the first step is to ask where >> that identity comes from and why you trust *that*. So perhaps you >> could start by laying out the setting you have in mind. >> > > The specifics are part of the stuff I'm working on currently (doing a > proof of concept), but at a 50,000 foot level: > > - The identity is generated by the server itself, and has a > corresponding DNS zone which is locally scoped (won't work outside the > local environment, for some value of "local), but globally unique. Mak= ing > the name a zone allows all the data to be DNSSEC signed and relies onl= y on > a single trust anchor specific to the server (the DNSKEY with SEP bit = set > for the zone itself). > - The trust for that requires some mechanism for distributing the > corresponding trust anchor. > > > - Maybe technically out of scope for the WG but definitely a > requirement to bootstrap securely. Potential methods might include: > - DHCP > - dot1x, or something similar > - unique-per-client name (but perhaps sharing a public key?) > - some demonstration that DHCP spoofing or RA spoofing is not > possible in the local environment (e.g. dot1x for port access, and = using > DHCP for obtaining the DNSKEY) > - Publication via other non-networked mechanisms, e.g. with QR > codes (under physical control of the operator), for example > - coffee shop paper slips with a QR code rather than just an > SSID, username, password (which don't prevent SSID spoofing) > - CCTV channels (hotels, conference display panels, etc) with QR > codes, or menus with QR codes. > - QR code published on a TLS-protected web site (e.g. conference > web site), available before traveling or on-site > - QR code on badges > - QR code on T-Shirts etc > - The QR code would need to encode the public key and name, and > would prevent spoofing since only the actual server would have the > necessary private key with which to sign the data. > - The trust of such a QR code and corresponding server is possibly > subjective, but at least under the control of whoever controls the = local > "meat-space" > - Advanced ideas could include things like rotating names and keys, > sync'd via a seed, on a physical (hardened) token with a display fo= r a QR > code. > > Thanks. That said, this seems like it reduces back to the unsolved problem of secure bootstrapping, and none of the alternatives you propose here seem very plausible. And if we assume that they *do* work, then there's no particular reason to mess around with special-use names and TLSA records: just distribute the IP address and the public key (or a hash of the key) directly. -Ekr The identity, being local in scope, can be changed as frequently as > necessary, potentially extremely frequently (every 15 minutes?). > Having a naming scheme with enough entropy is sufficient to prevent > collision and prevent guessing, thus making it more secure and/or more > trustworthy (I think). > > Eg. 12-characters of [LD] gives 36^12 combinations, or 4e21 or > thereabouts. Want more entropy? Add more characters. The base-36 > exponential curve gets very big, very fast. Making it machine-readable or > published electronically removes the UI/UX element from consideration. > > The locally significant aspect would be to place it in an unused and > un-assignable namespace, e.g. the ISO reserved 2-letter codes that were > discussed in DPRIVE or DNSOP (such as zz pseudo-TLD). > > The TLS aspect would generally require self-signed certs with TLSA type > 3-1-1 records published (EE public key fingerprint) for validation, and > would be in a 1:1 lock-step with the identity (and zone name). > > Assuming the POC works, I think most of the above aspects can be reduced > to bike-shedding. > > Brian > > >> >> -Ekr >> >> >>> >>> I'm reasonably confident at this point in making the following assertio= n: >>> >>> - The above dependencies are intractable. >>> - The root problem is that private addressing and private namespaces >>> are incompatible with CA-issued certificates, >>> - This effectively makes TLSA records the only feasible solution for >>> establishing TLS connections to any resolver which does not have a >>> published public name and public (non-RFC1918) address. >>> - TLSA (DANE) requires DNSSEC validation. >>> >>> Once the bootstrapping has been done, the TLS connections can be >>> established using the trusted resolver, and depending on the browser's >>> implementation choices, may exclude the use of DNSSEC validation. >>> >>> However, it is not possible to bootstrap to any resolver except those o= n >>> a hardcoded list and using certificates issued by CAs from browser-spec= ific >>> CA sets, unless client DNSSEC validation is available. >>> >>> This needs to be explicitly discussed as part of the WG charter scope >>> discussion. >>> >>> Brian >>> >>>> /a >>>> >>>> ____ >>>> [1] Yes, I recognize that "confidential" raises the question "from >>>> whom," and that the answer to that is the real underlying tension in t= his >>>> discussion. I'm not trying to give that part of the question short shr= ift; >>>> I'm eliding any such discussion because it is aggressively unrelated t= o my >>>> point. To be clear, my point is that the *other* question is basically >>>> uninteresting in this context. >>>> >>>> [2] Which makes question #2 largely irrelevant, since inaccuracies are >>>> detected during the subsequent TLS handshake. >>>> >>>> [3] https://letsencrypt.org/stats/#percent-pageloads >>>> >>> -- >>> Add mailing list >>> Add@ietf.org >>> https://www.ietf.org/mailman/listinfo/add >>> >> --000000000000a37cbf059b593fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 4, 2020 at 3:37 PM Brian = Dickson <brian.peter.di= ckson@gmail.com> wrote:


On Sat, Jan 4, 2020 = at 1:28 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Jan 3, 2020 = at 6:00 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:
=


On Thu, Jan 2, 2020 at 3:56 PM Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
[as an individual]

On 1/2/20 5:38 PM, Jim Reid wrote:
The debate about trust terminology/definitions is fascinating. I=
t's very likely to be a topic that the new WG-to-be could eventually di=
scuss. But it doesn't belong on this thread. Could we please branch thi=
s off somewhere else so this thread can focus on the charter proposals? Tha=
nks.


Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.



Respectfully, I disag= ree with this summary.

Briefly: I am discussing bo= otstrapping into the state of having a trusted resolver (that would then be= used for your HTTP stuff).

It is not necessarily = the case that every possible bootstrapping process can proceed without usin= g DNSSEC.

In particular, the issue generally categ= orized as "discovery" (but which very likely also encompasses rel= ated issues like resolver identity (name), reachability, forwarders and the= ir topologies, and related network issues (NAT)).

= This is an area I am currently actively working on.

Unless the WG wants to expressly reject the notion of "same resolver= " as a policy for encrypted DNS (which would put Mozilla at odds with = Google), I think it is premature to exclude DNSSEC validation on the client= , as part of that bootstrap process.
It might be helpful if you laid out what role you think cryptog= raphic
authentication is playing here.

Cryptographic authenticati= on, whether via WebPKI or DNSSEC/TLSA, ties
the server to a given identi= ty. So, the first step is to ask where
that identity comes from and why = you trust *that*. So perhaps you
could start by laying out the setting y= ou have in mind.

The = specifics are part of the stuff I'm working on currently (doing a proof= of concept), but at a 50,000 foot level:
  • The identity is= generated by the server itself, and has a corresponding DNS zone which is = locally scoped (won't work outside the local environment, for some valu= e of "local), but globally unique. Making the name a zone allows all t= he data to be DNSSEC signed and relies only on a single trust anchor specif= ic to the server (the DNSKEY with SEP bit set for the zone itself).
    • The trust for that requires some mechanism for distributing the correspond= ing trust anchor.=C2=A0
  • Maybe technically out o= f scope for the WG but definitely a requirement to bootstrap securely. Pote= ntial methods might include:
    • DHCP
    • dot1x, or something s= imilar
    • unique-per-client name (but perhaps sharing a public key?)
    • some demonstration that DHCP spoofing or RA spoofing is not possible= in the local environment (e.g. dot1x for port access, and using DHCP for o= btaining the DNSKEY)
    • Publication via other non-networked mechanisms= , e.g. with QR codes (under physical control of the operator), for example<= /li>
      • coffee shop paper slips with a QR code rather than just an SSID= , username, password (which don't prevent SSID spoofing)
      • CCTV c= hannels (hotels, conference display panels, etc) with QR codes, or menus wi= th QR codes.=C2=A0
      • QR code published on a TLS-protected web site (e= .g. conference web site), available before traveling or on-site
      • QR = code on badges
      • QR code on T-Shirts etc
    • The QR code wou= ld need to encode the public key and name, and would prevent spoofing since= only the actual server would have the necessary private key with which to = sign the data.
    • The trust of such a QR code and corresponding server= is possibly subjective, but at least under the control of whoever controls= the local "meat-space"
    • Advanced ideas could include thin= gs like rotating names and keys, sync'd via a seed, on a physical (hard= ened) token with a display for a QR code.
<= /blockquote>
Thanks.

That said, this seems lik= e it reduces back to the unsolved problem of secure bootstrapping, and none= of the alternatives you propose here seem very plausible. And if we assume= that they *do* work, then there's no particular reason to mess around = with special-use names and TLSA records: just distribute the IP address and= the public key (or a hash of the key) directly.

-Ekr

The identity, being loc= al in scope, can be changed as frequently as necessary, potentially extreme= ly frequently (every 15 minutes?).
Having a naming scheme with en= ough entropy is sufficient to prevent collision and prevent guessing, thus = making it more secure and/or more trustworthy (I think).=C2=A0
Eg. 12-characters of [LD] gives 36^12 combinations, or 4e21 or= thereabouts. Want more entropy? Add more characters. The base-36 exponenti= al curve gets very big, very fast. Making it machine-readable or published = electronically removes the UI/UX element from consideration.

=
The locally significant aspect would be to place it in an unused= and un-assignable namespace, e.g. the ISO reserved 2-letter codes that wer= e discussed in DPRIVE or DNSOP (such as zz pseudo-TLD).

The TLS aspect would generally require self-signed certs with TLSA ty= pe 3-1-1 records published (EE public key fingerprint) for validation, and = would be in a 1:1 lock-step with the identity (and zone name).
Assuming the POC works, I think most of the above aspects can = be reduced to bike-shedding.

Brian
=C2= =A0

-Ekr
=C2=A0

I'm reasonably confident at this point in making = the following assertion:
  • The above dependencies are intra= ctable.
  • The root problem is that private addressing and private nam= espaces are incompatible with CA-issued certificates,=C2=A0
  • This ef= fectively makes TLSA records the only feasible solution for establishing TL= S connections to any resolver which does not have a published public name a= nd public (non-RFC1918) address.
  • TLSA (DANE) requires DNSSEC valida= tion.
Once the bootstrapping has been done, the TLS con= nections can be established=C2=A0 using the trusted resolver, and depending= on the browser's implementation choices, may exclude the use of DNSSEC= validation.

However, it is not possible to bootst= rap to any resolver except those on a hardcoded list and using certificates= issued by CAs from browser-specific CA sets, unless client DNSSEC validati= on is available.

This needs to be explicitly discu= ssed as part of the WG charter scope discussion.

B= rian

/a

____
[1] Yes, I recognize that "confidential" raises the questio= n "from whom," and that the answer to that is the real underlying tensio= n in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000a37cbf059b593fef-- From nobody Sat Jan 4 18:58:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE681200A1 for ; Sat, 4 Jan 2020 18:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 lqmRfPGAQC8L for ; Sat, 4 Jan 2020 18:58:28 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 E6A8612008F for ; Sat, 4 Jan 2020 18:58:27 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id v12so29628959vsv.5 for ; Sat, 04 Jan 2020 18:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PZJL4x5Q/zzx8nV0zZk/JKJXVfcyX0fx7e1NZ4oz3Uk=; b=X+WfhxRQKRpCtUoRhIyBdwEmJyWvSgLdRaL9dIYEQ5/u0prTG6TdTitkcuEQggPbSv 5uFN345K5HASxZEymroXzCjGjNnvGM2J/lYf3U8QgKMnpjK581QFEHTtPQiPN8L6B83Z 5+DMK3abb1iw1LsnKL3iRXktjVdbA5NXU7AXJT34FL+V3Hr+YA16I4ftPf1egty565XW h8gCL7K2puye2iax1cWvs8Nm9een6lq2zI2EUBn2Kd6YhEJUnyqQFN4pocGlk0yQWIK5 YYmzhSHrDYZiyAxfTmtzVh0liKeHC/7sZFEyx35knXVBeaA7q00wAqaQtat6KhJurfPS ABKQ== 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=PZJL4x5Q/zzx8nV0zZk/JKJXVfcyX0fx7e1NZ4oz3Uk=; b=fqvhl2XvYBjRuL4cgWxE+lx0KdBN+AKYnM4a7/39uIuJpBbQiGtCkPYNM1SZAd6Tgd JW5CMrVoVPCQVlSwWEyd/faYNdHCu7NNsyDt6bymf35c1eQC97uvbWa2wywDCYaIQXzT kRSHqP2jyMvupKb7wTOaIN76p0MiZ7DooOz0RE66fNlptTlaTKqXthgkwg8JJedq+EIB NOGMpxLEpcE0weHN/0BwyxZ15cCo/6AjVdlbibN6ljNeXyX2QK2+PPnwcB8FIyS3I08g k72WpiBkkwnC30J8fPY3ow0gPV0AjVXFua9xE0aI2542QsIvwiH3zj85gW3vNlfPMw+X RdxQ== X-Gm-Message-State: APjAAAV0TWGbWLOESmSYC3f69k0sHjUVJ0oHl/vVpDva+vRspqKlovhk H0Eeig1qe8vgovBDBOjVvHUKRj8gGdtY+B18woCIQg== X-Google-Smtp-Source: APXvYqzbcVU9IQY7odt2ginlJp0jhZeg0wMgY/IUoX/R56r9YF70HWLIALHY7UBevhGc+7+IC3zmB4qKXbOLpci/3n8= X-Received: by 2002:a67:fc09:: with SMTP id o9mr50155007vsq.75.1578193106981; Sat, 04 Jan 2020 18:58:26 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> In-Reply-To: From: Brian Dickson Date: Sat, 4 Jan 2020 18:58:15 -0800 Message-ID: To: Eric Rescorla Cc: Adam Roach , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008759eb059b5bb7d7" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 02:58:31 -0000 --0000000000008759eb059b5bb7d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 4, 2020 at 4:01 PM Eric Rescorla wrote: > > > On Sat, Jan 4, 2020 at 3:37 PM Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> >> On Sat, Jan 4, 2020 at 1:28 PM Eric Rescorla wrote: >> >>> >>> >>> On Fri, Jan 3, 2020 at 6:00 PM Brian Dickson < >>> brian.peter.dickson@gmail.com> wrote: >>> >>>> >>>> >>>> On Thu, Jan 2, 2020 at 3:56 PM Adam Roach wrote: >>>> >>>>> [as an individual] >>>>> >>>>> On 1/2/20 5:38 PM, Jim Reid wrote: >>>>> >>>>> The debate about trust terminology/definitions is fascinating. It's v= ery likely to be a topic that the new WG-to-be could eventually discuss. Bu= t it doesn't belong on this thread. Could we please branch this off somewhe= re else so this thread can focus on the charter proposals? Thanks. >>>>> >>>>> >>>>> >>>>> Having read through this thread, I think there is a useful >>>>> charter-related distinction to be made here, and I think conflating t= hese >>>>> two things may be one reason people are talking past each other: >>>>> >>>>> >>>>> 1. Do I trust the question I ask to be confidential? [1] >>>>> 2. Do I trust the answer I get to be accurate? >>>>> >>>>> >>>>> Given that the only context apparently under discussion is web >>>>> browsers, and given that the vast majority of HTTP connections are >>>>> performed over TLS [2] [3], I suspect that #1 is the far more interes= ting >>>>> question, and the only one that really makes sense to focus on in the >>>>> charter. >>>>> >>>>> >>>>> >>>> Respectfully, I disagree with this summary. >>>> >>>> Briefly: I am discussing bootstrapping into the state of having a >>>> trusted resolver (that would then be used for your HTTP stuff). >>>> >>>> It is not necessarily the case that every possible bootstrapping >>>> process can proceed without using DNSSEC. >>>> >>>> In particular, the issue generally categorized as "discovery" (but >>>> which very likely also encompasses related issues like resolver identi= ty >>>> (name), reachability, forwarders and their topologies, and related net= work >>>> issues (NAT)). >>>> >>>> This is an area I am currently actively working on. >>>> >>>> Unless the WG wants to expressly reject the notion of "same resolver" >>>> as a policy for encrypted DNS (which would put Mozilla at odds with >>>> Google), I think it is premature to exclude DNSSEC validation on the >>>> client, as part of that bootstrap process. >>>> >>> >>> It might be helpful if you laid out what role you think cryptographic >>> authentication is playing here. >>> >>> Cryptographic authentication, whether via WebPKI or DNSSEC/TLSA, ties >>> the server to a given identity. So, the first step is to ask where >>> that identity comes from and why you trust *that*. So perhaps you >>> could start by laying out the setting you have in mind. >>> >> >> The specifics are part of the stuff I'm working on currently (doing a >> proof of concept), but at a 50,000 foot level: >> >> - The identity is generated by the server itself, and has a >> corresponding DNS zone which is locally scoped (won't work outside th= e >> local environment, for some value of "local), but globally unique. Ma= king >> the name a zone allows all the data to be DNSSEC signed and relies on= ly on >> a single trust anchor specific to the server (the DNSKEY with SEP bit= set >> for the zone itself). >> - The trust for that requires some mechanism for distributing the >> corresponding trust anchor. >> >> >> - Maybe technically out of scope for the WG but definitely a >> requirement to bootstrap securely. Potential methods might include: >> - DHCP >> - dot1x, or something similar >> - unique-per-client name (but perhaps sharing a public key?) >> - some demonstration that DHCP spoofing or RA spoofing is not >> possible in the local environment (e.g. dot1x for port access, and= using >> DHCP for obtaining the DNSKEY) >> - Publication via other non-networked mechanisms, e.g. with QR >> codes (under physical control of the operator), for example >> - coffee shop paper slips with a QR code rather than just an >> SSID, username, password (which don't prevent SSID spoofing) >> - CCTV channels (hotels, conference display panels, etc) with >> QR codes, or menus with QR codes. >> - QR code published on a TLS-protected web site (e.g. >> conference web site), available before traveling or on-site >> - QR code on badges >> - QR code on T-Shirts etc >> - The QR code would need to encode the public key and name, and >> would prevent spoofing since only the actual server would have the >> necessary private key with which to sign the data. >> - The trust of such a QR code and corresponding server is possibly >> subjective, but at least under the control of whoever controls the= local >> "meat-space" >> - Advanced ideas could include things like rotating names and >> keys, sync'd via a seed, on a physical (hardened) token with a dis= play for >> a QR code. >> >> Thanks. > > That said, this seems like it reduces back to the unsolved problem of > secure bootstrapping, and none of the alternatives you propose here seem > very plausible. And if we assume that they *do* work, then there's no > particular reason to mess around with special-use names and TLSA records: > just distribute the IP address and the public key (or a hash of the key) > directly. > The latter would only work if the only kind of server were resolver, and if no forwarders existed. The discovery stuff is all about actually determining (among non-malicious servers which are already "trusted" by virtue of being used via existing mechanisms) what servers are actually doing resolving (versus only being forwarders). It is not possible via in-band query to determine from the perspective of a client (stub) whether a server is a forwarder or resolver. It is equally impossible from the server side to determine if the client is a forwarder or an actual client. I agree, that if it not for this issue, the IP and pubkey would be sufficient. The problem is that establishing a TLS connection to a forwarder (which forwards the query to another server) is not in the same class of privacy protection as having a TLS connection to the eventual upstream resolver (relative to the first forwarder). Using the actual resolver would maximize the privacy benefit, without changing where resolution is being done per se. That's the goal of the stuff I'm working on -- allow the client to figure out who the resolver(s) available are, and whether the resolver(s) do DoT or DoH, and respect whatever the client's preferred policy is (i.e. using DoT and/or DoH, if the client requests such), by only sending the queries over the appropriate connection type, to one of the existing resolvers that could be providing resolution. (The forwarder could have a "tree" of upstream forwarders, and a number of "leaf" resolvers, only some of which do TLS. The objective is, bypass the forwarders and talk TLS to one or more resolvers, using whatever other underlying resolver selection logic exists to pick the best among those.) The plausibility depends (as is the case for pretty much everything in the IETF) on implementation and deployment. However, the reverse is also true; if you don't buy a ticket (write a spec), you can't win (have interoperable deployment at all). It's premature at this point to try to evaluate anything from 50,000 feet, so let's leave it (plausibility) as an open question, thanks. Brian > > -Ekr > > The identity, being local in scope, can be changed as frequently as >> necessary, potentially extremely frequently (every 15 minutes?). >> Having a naming scheme with enough entropy is sufficient to prevent >> collision and prevent guessing, thus making it more secure and/or more >> trustworthy (I think). >> >> Eg. 12-characters of [LD] gives 36^12 combinations, or 4e21 or >> thereabouts. Want more entropy? Add more characters. The base-36 >> exponential curve gets very big, very fast. Making it machine-readable o= r >> published electronically removes the UI/UX element from consideration. >> >> The locally significant aspect would be to place it in an unused and >> un-assignable namespace, e.g. the ISO reserved 2-letter codes that were >> discussed in DPRIVE or DNSOP (such as zz pseudo-TLD). >> >> The TLS aspect would generally require self-signed certs with TLSA type >> 3-1-1 records published (EE public key fingerprint) for validation, and >> would be in a 1:1 lock-step with the identity (and zone name). >> >> Assuming the POC works, I think most of the above aspects can be reduced >> to bike-shedding. >> >> Brian >> >> >>> >>> -Ekr >>> >>> >>>> >>>> I'm reasonably confident at this point in making the following >>>> assertion: >>>> >>>> - The above dependencies are intractable. >>>> - The root problem is that private addressing and private >>>> namespaces are incompatible with CA-issued certificates, >>>> - This effectively makes TLSA records the only feasible solution >>>> for establishing TLS connections to any resolver which does not hav= e a >>>> published public name and public (non-RFC1918) address. >>>> - TLSA (DANE) requires DNSSEC validation. >>>> >>>> Once the bootstrapping has been done, the TLS connections can be >>>> established using the trusted resolver, and depending on the browser'= s >>>> implementation choices, may exclude the use of DNSSEC validation. >>>> >>>> However, it is not possible to bootstrap to any resolver except those >>>> on a hardcoded list and using certificates issued by CAs from >>>> browser-specific CA sets, unless client DNSSEC validation is available= . >>>> >>>> This needs to be explicitly discussed as part of the WG charter scope >>>> discussion. >>>> >>>> Brian >>>> >>>>> /a >>>>> >>>>> ____ >>>>> [1] Yes, I recognize that "confidential" raises the question "from >>>>> whom," and that the answer to that is the real underlying tension in = this >>>>> discussion. I'm not trying to give that part of the question short sh= rift; >>>>> I'm eliding any such discussion because it is aggressively unrelated = to my >>>>> point. To be clear, my point is that the *other* question is basicall= y >>>>> uninteresting in this context. >>>>> >>>>> [2] Which makes question #2 largely irrelevant, since inaccuracies ar= e >>>>> detected during the subsequent TLS handshake. >>>>> >>>>> [3] https://letsencrypt.org/stats/#percent-pageloads >>>>> >>>> -- >>>> Add mailing list >>>> Add@ietf.org >>>> https://www.ietf.org/mailman/listinfo/add >>>> >>> --0000000000008759eb059b5bb7d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 4, 2020 at 4:01 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Sat, Jan 4, 2020 at 3:37 PM Brian Dickson <brian.peter.dic= kson@gmail.com> wrote:


On Sat, Jan 4, 2020 at = 1:28 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Jan 3, 2020 at 6= :00 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:


On Thu, Jan 2, 2020 at 3:56 PM Adam Roach <adam@nostrum.com> wrote:
=
=20 =20 =20
[as an individual]

On 1/2/20 5:38 PM, Jim Reid wrote:
The debate about trust terminology/definitions is fascinating. I=
t's very likely to be a topic that the new WG-to-be could eventually di=
scuss. But it doesn't belong on this thread. Could we please branch thi=
s off somewhere else so this thread can focus on the charter proposals? Tha=
nks.


Having read through this thread, I think there is a useful charter-related distinction to be made here, and I think conflating these two things may be one reason people are talking past each other:

  1. Do I trust the question I ask to be confidential? [1]
  2. Do I trust the answer I get to be accurate?


Given that the only context apparently under discussion is web browsers, and given that the vast majority of HTTP connections are performed over TLS [2] [3], I suspect that #1 is the far more interesting question, and the only one that really makes sense to focus on in the charter.



Respectfully, I disag= ree with this summary.

Briefly: I am discussing bo= otstrapping into the state of having a trusted resolver (that would then be= used for your HTTP stuff).

It is not necessarily = the case that every possible bootstrapping process can proceed without usin= g DNSSEC.

In particular, the issue generally categ= orized as "discovery" (but which very likely also encompasses rel= ated issues like resolver identity (name), reachability, forwarders and the= ir topologies, and related network issues (NAT)).

= This is an area I am currently actively working on.

Unless the WG wants to expressly reject the notion of "same resolver= " as a policy for encrypted DNS (which would put Mozilla at odds with = Google), I think it is premature to exclude DNSSEC validation on the client= , as part of that bootstrap process.
It might be helpful if you laid out what role you think cryptog= raphic
authentication is playing here.

Cryptographic authenticati= on, whether via WebPKI or DNSSEC/TLSA, ties
the server to a given identi= ty. So, the first step is to ask where
that identity comes from and why = you trust *that*. So perhaps you
could start by laying out the setting y= ou have in mind.

The = specifics are part of the stuff I'm working on currently (doing a proof= of concept), but at a 50,000 foot level:
  • The identity is= generated by the server itself, and has a corresponding DNS zone which is = locally scoped (won't work outside the local environment, for some valu= e of "local), but globally unique. Making the name a zone allows all t= he data to be DNSSEC signed and relies only on a single trust anchor specif= ic to the server (the DNSKEY with SEP bit set for the zone itself).
    • The trust for that requires some mechanism for distributing the correspond= ing trust anchor.=C2=A0
  • Maybe technically out o= f scope for the WG but definitely a requirement to bootstrap securely. Pote= ntial methods might include:
    • DHCP
    • dot1x, or something s= imilar
    • unique-per-client name (but perhaps sharing a public key?)
    • some demonstration that DHCP spoofing or RA spoofing is not possible= in the local environment (e.g. dot1x for port access, and using DHCP for o= btaining the DNSKEY)
    • Publication via other non-networked mechanisms= , e.g. with QR codes (under physical control of the operator), for example<= /li>
      • coffee shop paper slips with a QR code rather than just an SSID= , username, password (which don't prevent SSID spoofing)
      • CCTV c= hannels (hotels, conference display panels, etc) with QR codes, or menus wi= th QR codes.=C2=A0
      • QR code published on a TLS-protected web site (e= .g. conference web site), available before traveling or on-site
      • QR = code on badges
      • QR code on T-Shirts etc
    • The QR code wou= ld need to encode the public key and name, and would prevent spoofing since= only the actual server would have the necessary private key with which to = sign the data.
    • The trust of such a QR code and corresponding server= is possibly subjective, but at least under the control of whoever controls= the local "meat-space"
    • Advanced ideas could include thin= gs like rotating names and keys, sync'd via a seed, on a physical (hard= ened) token with a display for a QR code.
<= /blockquote>
Thanks.

That said, this seems lik= e it reduces back to the unsolved problem of secure bootstrapping, and none= of the alternatives you propose here seem very plausible. And if we assume= that they *do* work, then there's no particular reason to mess around = with special-use names and TLSA records: just distribute the IP address and= the public key (or a hash of the key) directly.

The latter would only work if the only kind of = server were resolver, and if no forwarders existed.

The discovery stuff is all about actually determining (among non-maliciou= s servers which are already "trusted" by virtue of being used via= existing mechanisms) what servers are actually doing resolving (versus onl= y being forwarders).

It is not possible via in-ban= d query to determine from the perspective of a client (stub) whether a serv= er is a forwarder or resolver. It is equally impossible from the server sid= e to determine if the client is a forwarder or an actual client.
=
I agree, that if it not for this issue, the IP and pubkey wo= uld be sufficient.

The problem is that establishin= g a TLS connection to a forwarder (which forwards the query to another serv= er) is not in the same class of privacy protection as having a TLS connecti= on to the eventual upstream resolver (relative to the first forwarder).

Using the actual resolver would maximize the privacy = benefit, without changing where resolution is being done per se.
=
That's the goal of the stuff I'm working on -- allow= the client to figure out who the resolver(s) available are, and whether th= e resolver(s) do DoT or DoH, and respect whatever the client's preferre= d=C2=A0 policy is (i.e. using DoT and/or DoH, if the client requests such),= by only sending the queries over the appropriate connection type, to one o= f the existing resolvers that could be providing resolution.

=
(The forwarder could have a "tree" of upstream forward= ers, and a number of "leaf" resolvers, only some of which do TLS.= The objective is, bypass the forwarders and talk TLS to one or more resolv= ers, using whatever other underlying resolver selection logic exists to pic= k the best among those.)

The plausibility depends = (as is the case for pretty much everything in the IETF) on implementation a= nd deployment.=C2=A0
However, the reverse is also true; if you do= n't buy a ticket (write a spec), you can't win (have interoperable = deployment at all).

It's premature at this poi= nt to try to evaluate anything from 50,000 feet, so let's leave it (pla= usibility) as an open question, thanks.=C2=A0

Bria= n

=C2=A0
<= br>
-Ekr

The identity= , being local in scope, can be changed as frequently as necessary, potentia= lly extremely frequently (every 15 minutes?).
Having a naming sch= eme with enough entropy is sufficient to prevent collision and prevent gues= sing, thus making it more secure and/or more trustworthy (I think).=C2=A0

Eg. 12-characters of [LD] gives 36^12 combinations,= or 4e21 or thereabouts. Want more entropy? Add more characters. The base-3= 6 exponential curve gets very big, very fast. Making it machine-readable or= published electronically removes the UI/UX element from consideration.

The locally significant aspect would be to place it i= n an unused and un-assignable namespace, e.g. the ISO reserved 2-letter cod= es that were discussed in DPRIVE or DNSOP (such as zz pseudo-TLD).

The TLS aspect would generally require self-signed certs w= ith TLSA type 3-1-1 records published (EE public key fingerprint) for valid= ation, and would be in a 1:1 lock-step with the identity (and zone name).

Assuming the POC works, I think most of the above a= spects can be reduced to bike-shedding.

Brian
=C2=A0

-Ekr
=C2=A0

I'm reasonably confident at this point in= making the following assertion:
  • The above dependencies a= re intractable.
  • The root problem is that private addressing and pri= vate namespaces are incompatible with CA-issued certificates,=C2=A0
    • This effectively makes TLSA records the only feasible solution for establi= shing TLS connections to any resolver which does not have a published publi= c name and public (non-RFC1918) address.
  • TLSA (DANE) requires DNSSE= C validation.
Once the bootstrapping has been done, the= TLS connections can be established=C2=A0 using the trusted resolver, and d= epending on the browser's implementation choices, may exclude the use o= f DNSSEC validation.

However, it is not possible t= o bootstrap to any resolver except those on a hardcoded list and using cert= ificates issued by CAs from browser-specific CA sets, unless client DNSSEC = validation is available.

This needs to be explicit= ly discussed as part of the WG charter scope discussion.

Brian

/a

____
[1] Yes, I recognize that "confidential" raises the questio= n "from whom," and that the answer to that is the real underlying tensio= n in this discussion. I'm not trying to give that part of the question short shrift; I'm eliding any such discussion because it is aggressively unrelated to my point. To be clear, my point is that the *other* question is basically uninteresting in this context.

[2] Which makes question #2 largely irrelevant, since inaccuracies are detected during the subsequent TLS handshake.

[3] https://letsencrypt.org/stats/#percent-pageloads

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000008759eb059b5bb7d7-- From nobody Sun Jan 5 04:43:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0432120098 for ; Sun, 5 Jan 2020 04:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 E2_LfMvErVJd for ; Sun, 5 Jan 2020 04:43:22 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5632120019 for ; Sun, 5 Jan 2020 04:43:22 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id z193so45979807iof.1 for ; Sun, 05 Jan 2020 04:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E9dPtpo+lojZVeYCOOE+e0DvHVOix9o/5uV82zKatvI=; b=xe9M5YMHvRXd/9RpB/3UbBrfLlDFHqgfeMhNs5KdW15916ELPyD3PMaHDRjH9S7Eg8 ksaScpKUPMC6aYx5kec4xtZB2jcQFbfNh+aO9xNEDJcjtpHJ7EO/KynqdQwiCiC15q9F UuTw5KYUj6VFyUw3hqQ8bCBBfMy4dl0sloefQTdJNniL5WRZlX/niGYyM7uHBDeutql3 yzs7VX4+TSB3yNCL6JJHbRz0xVc4PXpGiSSpbkAobVnmeCWox6Uf3LOPV7pE/3NzmamF o0DFsXbk4ODAEhfq4f1g6J19PqmYhbx/2ZFk92MjMC/ax5QTU2tWjaO4RndQw2IH513i QQ3w== 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=E9dPtpo+lojZVeYCOOE+e0DvHVOix9o/5uV82zKatvI=; b=bM+rsR6Il7asxBSlp2xRX1hLLwYCku7k35LLvbCP172y3BiP1Y2+5PEAhwRyTvp2oY y1aWeQCiPn4zbh1j6ckF2pIsfqjeNY4qAehbtHqI0iXYil+1jA8LYblFsQRbcl8QQjj5 qTF1TZyBDOxlRJpOfwEXBe6BjFlwoNKHuTj1FmL2AQ/QGJyerDnMT/W40ENUvGZpL9Dn /6+7yvl9IUcauwmdDEl+M5LgCW6pOkbAqFsATMqWDiQCrt2gAzLWZqDpGITA6OUvHeK7 0dghSEJsbGXUZ0bX+su8UyX4mVTeFSuv7w3g3a/KjBiF19FeV5+qw+BubAhFJ4741pSd zHoQ== X-Gm-Message-State: APjAAAUB2PVzT93N8vIGIH/7omER7brNT7Ez6dLUOWIhUuqNiy6th0W2 8BPfxzLkpLcaSmnmmZgaJdrqLw== X-Google-Smtp-Source: APXvYqz1Akpgqzt7y4hMG+LxJeYyjzm+AB6Bg8kV7KESCRMJZ1jQaE9lAzDl0FF68ggLJ358liISuQ== X-Received: by 2002:a5e:c601:: with SMTP id f1mr66992850iok.208.1578228202112; Sun, 05 Jan 2020 04:43:22 -0800 (PST) Received: from [172.19.0.55] ([75.104.91.151]) by smtp.gmail.com with ESMTPSA id l22sm23095551ilh.37.2020.01.05.04.43.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jan 2020 04:43:21 -0800 (PST) From: Ted Lemon Message-Id: <080A70BB-C7D0-40FF-A1C2-BB3D5C4AF749@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A39A4880-DE63-43FE-8BFA-846AF23F2886" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Sun, 5 Jan 2020 07:43:10 -0500 In-Reply-To: Cc: Eric Rescorla , ADD Mailing list , Adam Roach To: Brian Dickson References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 12:43:25 -0000 --Apple-Mail=_A39A4880-DE63-43FE-8BFA-846AF23F2886 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 4, 2020, at 9:58 PM, Brian Dickson = wrote: > (The forwarder could have a "tree" of upstream forwarders, and a = number of "leaf" resolvers, only some of which do TLS. The objective is, = bypass the forwarders and talk TLS to one or more resolvers, using = whatever other underlying resolver selection logic exists to pick the = best among those.) This sounds really complicated. What is the problem you are trying to = solve that requires so much complexity? --Apple-Mail=_A39A4880-DE63-43FE-8BFA-846AF23F2886 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 4, 2020, at 9:58 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
(The forwarder could have a "tree" of upstream forwarders, = and a number of "leaf" resolvers, only some of which do TLS. The = objective is, bypass the forwarders and talk TLS to one or more = resolvers, using whatever other underlying resolver selection logic = exists to pick the best among those.)

This sounds really complicated.  What is = the problem you are trying to solve that requires so much = complexity?

= --Apple-Mail=_A39A4880-DE63-43FE-8BFA-846AF23F2886-- From nobody Sun Jan 5 06:39:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7748E12008B for ; Sun, 5 Jan 2020 06:39:18 -0800 (PST) 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 szJiepMLg_8T for ; Sun, 5 Jan 2020 06:39:16 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 5EF6912004C for ; Sun, 5 Jan 2020 06:39:16 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id a13so48358028ljm.10 for ; Sun, 05 Jan 2020 06:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GDSIKZRh3r0RKAT7sI4AUhdbhJ3lpAsggGT8x+SM4VQ=; b=BTi+qVCvb7ABlZ6l6p5wV6R6p6MflTdQkpcxHfe436Lao3uraJ6Q5tyH6GoosPKnZa UEbqSpcpR9gP+7zhdEs3uagK4rOYGOc6Eb1M9CbQcPASyATfs+fL85YYClHQP1LG3hqj 6ei4H2aTWs776mQ++Vi5r6qBUzghQ9W2PG9SF1XZQ08oGyzdqxSN0klBccSpXhhfZyYB xumS5bEEAnKZSM4O1uvJmF1sI/IQCOtExHhBCZqdrSDiUW4VHxCdGfZqNQVFTMLBoQaP 7L0pTK4x5OFj7S1fi6uxb07EoVJ4PxQRi2deolQ7xEooTf8VKVCiSmdT6QJElXPyckpP tF8w== 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=GDSIKZRh3r0RKAT7sI4AUhdbhJ3lpAsggGT8x+SM4VQ=; b=WGsMCXXkBZBTqNrAczwLiHo2DtJhMuw0wtVr82rtWQB7fbF6yN1x2qFcVGu3JoAclc LGkhEjiqqq0LdFMfpRk1hmtgt8wm6siz8Q+OxuW/Fs9LXDqa02H0cTIMRK0398/VWhCN 3jsxRAKUzWJTL98X/wkWLmf2BnNIDxhn/SJhH7TQZDG9J41zzVgBIC+c5Xo+wgSZpQiz gMiIb33YJa5p92bsegfyUadHyLc/FOqmhX3WsGjDML2yt+KSf6mICjY+1+HAKU281/rD kmi3Fuu2FHuVPJy6/a7hBGYqkjeDYOCSnANVVf2aCZCxXCmAWdloS/XImZU8qphbcg2L jGGQ== X-Gm-Message-State: APjAAAUTayVLJU3kqGexOpadEIWaNRhhfAZQ7bzuVBkI0v85228wgYqX I17JXWDUHhSpfTsL3dPiarKSZY4/ZXREO9imJjeGdw== X-Google-Smtp-Source: APXvYqwq4zWu9Dw/vOPoXmDGZ3iPDcNxBMKbUXYGLsn98ZFSL3exRqVRC8Kcaigh4Qr3vwmik4HXSyllVIzSpBV9V7Y= X-Received: by 2002:a2e:95c4:: with SMTP id y4mr57482122ljh.38.1578235154685; Sun, 05 Jan 2020 06:39:14 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> <080A70BB-C7D0-40FF-A1C2-BB3D5C4AF749@fugue.com> In-Reply-To: <080A70BB-C7D0-40FF-A1C2-BB3D5C4AF749@fugue.com> From: Eric Rescorla Date: Sun, 5 Jan 2020 06:38:38 -0800 Message-ID: To: Ted Lemon Cc: Brian Dickson , ADD Mailing list , Adam Roach Content-Type: multipart/alternative; boundary="000000000000c4728b059b658135" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 14:39:19 -0000 --000000000000c4728b059b658135 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 5, 2020 at 4:43 AM Ted Lemon wrote: > On Jan 4, 2020, at 9:58 PM, Brian Dickson > wrote: > > (The forwarder could have a "tree" of upstream forwarders, and a number of > "leaf" resolvers, only some of which do TLS. The objective is, bypass the > forwarders and talk TLS to one or more resolvers, using whatever other > underlying resolver selection logic exists to pick the best among those.) > > > This sounds really complicated. What is the problem you are trying to > solve that requires so much complexity? > I agree with Ted. This seems insufficiently developed to be a in a charter we are writing now. -Ekr --000000000000c4728b059b658135 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 5, 2020 at 4:43 AM Ted Le= mon <mellon@fugue.com> wrote:=
On Jan 4, 2020, at 9:58 PM, Brian Dickson <brian.pete= r.dickson@gmail.com> wrote:
(The forwarder could have a &quo= t;tree" of upstream forwarders, and a number of "leaf" resol= vers, only some of which do TLS. The objective is, bypass the forwarders an= d talk TLS to one or more resolvers, using whatever other underlying resolv= er selection logic exists to pick the best among those.)

This sounds really complicated.=C2=A0 What is the pro= blem you are trying to solve that requires so much complexity?
<= /blockquote>

I agree with Ted. This seems insufficiently= developed to be a in a charter we are writing now.

-Ekr

--000000000000c4728b059b658135-- From nobody Sun Jan 5 12:30:05 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122CA120058 for ; Sun, 5 Jan 2020 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 QVqUyLhRIOSo for ; Sun, 5 Jan 2020 12:30:01 -0800 (PST) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 C070912004F for ; Sun, 5 Jan 2020 12:30:00 -0800 (PST) Received: by mail-ua1-x933.google.com with SMTP id 73so16415496uac.6 for ; Sun, 05 Jan 2020 12:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y0Pa7P/XMKD3aEu6bZvvxOO3w7qd8mWQueLzn27lNSA=; b=UXcN/RTVn5jom27hrYSAXG4aiEbqGwPobVK7CsFM3lgbTr4BuejkMRjNM/JnrS1C76 iLXXTiYRm3nTd+XinLsfUjZBx49N9wvN1hbse9bq4R9IQ4fZv6PC5IIgE7DLYwon/t2U UNlDozDAO1999iEBKNt9rVBAZ7iBPvUJQoAl+O6X4QxOUMTh7bNLUYUtaRD9O6HkD8Px 8Fy+Y1x9q9lYlRp4vqRy6ehKVJqVdPz+37b4asTFxptk7l63qEOGBBDH2PH1VYr4ZI7I 5wdf8KLiAb8qnL/T+Ri2Vf41yXRgf4UNZLt/L1rQcqs1rd/EbNg962zZbF2s1g7krhCo O4mg== 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=y0Pa7P/XMKD3aEu6bZvvxOO3w7qd8mWQueLzn27lNSA=; b=bK67oAa8mVYC2p0lYgNVK/+bMyrXE7jDHTmrw73m7+jBDMbPEWcRj8yiV9af36PiD9 7OB3EjN1sOBSBly0oa/WAhz8wtVe33NVRQ1TpLJBQA8HwbSzaS08XUax+pS4q8Fei27w xSZQTxWt73RUImjlcCtMjgP/dFwBsFOei++NCdclh+LChJ+sjKpT+fgjrB9+kiZWlsq3 PmsWSqqrexCOnjd3NHSwLD57hxxRigdoCjvC5jdX6SAokFV9EWCQv1w0yLk0spPuTAw2 jwuz9L05mFMyIOu65kPoPrc++TP51tt8cVh9VlLGI1hNTEKJhyNUbyqBll7CcLMhY9sY QdIQ== X-Gm-Message-State: APjAAAUf401+g4sKrqjtImouTiAXNd16ScAp/lkSVSnWLssHBdww5Dpb 75wMTBsqEf0KfUmmb3Q+v9p29zzWFjMD5TjlPW4= X-Google-Smtp-Source: APXvYqzNvBkzEull7YHhGGDhg3gfQYkJQ4mIL094eBd9AwY83EQ9xaqsmMTh/N+7FNwa0pg0Q4dGY1Kh/Za0YwE5YEE= X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr57983608uar.62.1578256199766; Sun, 05 Jan 2020 12:29:59 -0800 (PST) MIME-Version: 1.0 References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> <080A70BB-C7D0-40FF-A1C2-BB3D5C4AF749@fugue.com> In-Reply-To: <080A70BB-C7D0-40FF-A1C2-BB3D5C4AF749@fugue.com> From: Brian Dickson Date: Sun, 5 Jan 2020 12:29:48 -0800 Message-ID: To: Ted Lemon Cc: Eric Rescorla , ADD Mailing list , Adam Roach Content-Type: multipart/alternative; boundary="00000000000026db46059b6a6834" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 20:30:03 -0000 --00000000000026db46059b6a6834 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 5, 2020 at 4:43 AM Ted Lemon wrote: > On Jan 4, 2020, at 9:58 PM, Brian Dickson > wrote: > > (The forwarder could have a "tree" of upstream forwarders, and a number of > "leaf" resolvers, only some of which do TLS. The objective is, bypass the > forwarders and talk TLS to one or more resolvers, using whatever other > underlying resolver selection logic exists to pick the best among those.) > > > This sounds really complicated. What is the problem you are trying to > solve that requires so much complexity? > Resolver discovery. Specifically, resolver discovery to upgrade the resolution to TLS (DoT or DoH), without changing the selection of resolver(s). If discovery is done in-band using DNS (e.g. with a well-known name), this automatically means that only the closest server in the forwarder "tree" will be discovered. The goal of discovery shouldn't be to discovery the closest TLS speaker. The goal should be to discover the resolver(s) being used, and whether TLS is supported. The purpose of the discovery is to enable privacy protection using TLS to a resolver. Doing TLS upgrade to a forwarder does not accomplish the privacy goal of ADD, if the forwarder itself is not doing TLS to its upstream(s), even if the forwarder is trusted. (I trust I don't need to explain why.) Similarly, if the forwarder does not support TLS, but the resolver it is using does support TLS, making a direct connection to the resolver via TLS is both necessary and sufficient to achieve the privacy goal of ADD. I agree, what I described sounds complicated. However, what it is doing is using a very well-known and familiar algorithm, https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm. If a forwarder is using the same mechanism as a resolver (to allow discovery), that has the side effect of preventing the client from directly reaching the resolver to do discovery. If the spec for discovery is to handle this situation, the forwarder needs to do discovery towards its upstream, and publish that information for the client's consumption. Each of those elements of discovery (client-forwarder, forwarder-upstream) is what amounts to a "link state". ("Link" meaning forwarder-upstream discovery information, "state" referring to TLS-or-not, including DoT vs DoH.) The client obtains all the link state information, runs it through Dijkstra, and finds one or more TLS resolvers it can use, and if more than one is available, selects the best (for some value of best). NB: One possible outcome for the algorithm is that the client decides that the full path of forwarders is all-TLS, and that it trusts the TLS state of the forwarders, and connects to the first forwarder using TLS. That choice is for the client to make. (Here client refers to application, not necessarily something exposed to the user of the application.) Dijkstra is very simple, it's undergrad level computer science stuff, and widely used on the Internet in the OSFP and ISIS routing protocols. It only sounds complicated. The forwarder issue exists but is only a problem if a forwarder gets "upgraded" to do the resolver discovery support. At that point, the analogy would be all of the fine IETF stuff that got broke by NAT. Rather than doing work that gets broken by not taking it into consideration, the goal here is to handle the problem in a way that is baked into the discovery mechanism. The problem being solved is simple to describe: resolver discovery. Putting that into the charter as something to try to solve makes sense. The upstream discovery part is very simple. The only time any complexity arises is if (a) there are forwarders, and (b) the forwarders implement the same discovery support as resolvers. The complexity is not itself part of the discovery mechanism, which remains very simple (the "link state" component that gets encoded in the discovery mechanism), The complexity is on the client where Dijkstra is used to select a resolver. And the Dijkstra only needs to be run if the topology learned is not simple. If forwarders exist, but are not implementing discovery, the regular mechanism for discovering the resolver itself "just works", and no Dijkstra is necessary. The complex parts, if necessary, are only invoked once, during the TLS bootstrap. That bootstrap may need to be re-run whenever the client moves between networks. This is just the upgrade being re-run, if the resolver choice is dynamic such as DHCP or via RA. All of this is only required if the resolver has not been hard-coded, so it does not affect any other parts of the client, only the part handling "same resolver" policy when the resolver is not on a list of known resolvers. TL;DR: it's not that complicated, I just did a poor job of describing "link state" and Dijkstra. It's only needed to make resolver discovery reliable. Brian --00000000000026db46059b6a6834 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 5, 2020 at 4:43 AM Ted Le= mon <mellon@fugue.com> wrote:=
On Jan 4, 2020, at 9:58 PM, Brian Dickson <brian.pete= r.dickson@gmail.com> wrote:
(The forwarder could have a &quo= t;tree" of upstream forwarders, and a number of "leaf" resol= vers, only some of which do TLS. The objective is, bypass the forwarders an= d talk TLS to one or more resolvers, using whatever other underlying resolv= er selection logic exists to pick the best among those.)

This sounds really complicated.=C2=A0 What is the pro= blem you are trying to solve that requires so much complexity?
<= /blockquote>

Resolver discovery.

Specifically, resolver=C2=A0discovery to upgrade the resolution to TLS (D= oT or DoH), without changing the selection of resolver(s).

If discovery is done in-band using DNS (e.g. with a well-know= n name), this automatically means that only the closest server in the forwa= rder "tree" will be discovered.
The goal of discovery s= houldn't be to discovery the closest TLS speaker.=C2=A0
The g= oal should be to discover the resolver(s) being used, and whether TLS is su= pported.=C2=A0
The purpose of the discovery is to enable privacy = protection using TLS to a resolver.

Doing TL= S upgrade to a forwarder does not accomplish the privacy goal of ADD, if th= e forwarder itself is not doing TLS to its upstream(s), even if the forward= er is trusted. (I trust I don't need to explain why.)

Similarly, if the forwarder does not support TLS, but the resolver = it is using does support TLS, making a direct connection to the resolver vi= a TLS is both necessary and sufficient to achieve the privacy goal of ADD.<= /div>

I agree, what I described sounds complicated. Howe= ver, what it is doing is using a very well-known and familiar algorithm,=C2= =A0https:/= /en.wikipedia.org/wiki/Dijkstra%27s_algorithm.

If a forwarder is=C2=A0using the same mechanism as a resolver (to allow di= scovery), that has the side effect of preventing the client from directly r= eaching the resolver to do discovery.
If the spec for discovery i= s to handle this situation, the forwarder needs to do discovery towards its= upstream, and publish that information for the client's consumption.
Each of those elements of discovery (client-forwarder, forwarder-u= pstream) is what amounts to a "link state". ("Link" mea= ning forwarder-upstream discovery information, "state" referring = to TLS-or-not, including DoT vs DoH.)
The client obtains all the = link state information, runs it through Dijkstra, and finds one or more TLS= resolvers it can use, and if more than one is available, selects the best = (for some value of best).

NB: One possible outcome= for the algorithm is that the client decides that the full path of forward= ers is all-TLS, and that it trusts the TLS state of the forwarders, and con= nects to the first forwarder using TLS. That choice is for the client to ma= ke. (Here client refers to application, not necessarily something exposed t= o the user of the application.)

Dijkstra is very s= imple, it's undergrad level computer science stuff, and widely used on = the Internet in the OSFP and ISIS routing protocols. It only sounds complic= ated.

The forwarder issue exists but is only a pro= blem if a forwarder gets "upgraded" to do the resolver discovery = support. At that point, the analogy would be all of the fine IETF stuff tha= t got broke by NAT. Rather than doing work that gets broken by not taking i= t into consideration, the goal here is to handle the problem in a way that = is baked into the discovery mechanism.

The problem= being solved is simple to describe: resolver discovery. Putting that into = the charter as something to try to solve makes sense.

<= div>The upstream discovery part is very simple. The only time any complexit= y arises is if (a) there are forwarders, and (b) the forwarders implement t= he same discovery support as resolvers.=C2=A0
The complexity is n= ot itself part of the discovery mechanism, which remains very simple (the &= quot;link state" component that gets encoded in the discovery mechanis= m),=C2=A0
The complexity is on the client where Dijkstra is used = to select a resolver.=C2=A0
And the Dijkstra only needs to be run= if the topology learned is not simple.=C2=A0
If forwarders exist= , but are not implementing discovery, the regular mechanism for discovering= the resolver itself "just works", and no Dijkstra is necessary.<= /div>
The complex parts, if necessary, are only invoked once, during th= e TLS bootstrap.=C2=A0
That bootstrap may need to be re-run whene= ver the client moves between networks. This is just the upgrade being re-ru= n, if the resolver choice is dynamic such as DHCP or via RA.

=
All of this is only required if the resolver has not been hard-c= oded, so it does not affect any other parts of the client, only the part ha= ndling "same resolver" policy when the resolver is not on a list = of known resolvers.

TL;DR: it's not that compl= icated, I just did a poor job of describing "link state" and Dijk= stra. It's only needed to make resolver discovery reliable.
<= br>
Brian


--00000000000026db46059b6a6834-- From nobody Sun Jan 5 12:34:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECE112004F for ; Sun, 5 Jan 2020 12:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 t218li-hyrBP for ; Sun, 5 Jan 2020 12:34:56 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 EF706120033 for ; Sun, 5 Jan 2020 12:34:55 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id f5so41008516ilq.5 for ; Sun, 05 Jan 2020 12:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KyjlWpygF8iBQPt2JPewFu0EYxma3wLGxqS/oi6tK9k=; b=UDdbPYyFuRONoRR0WDmVueD29jds0bb0v94F1xBuOwK/oIe85sosu4Xv5swBUF54UE c1XHVAva5tWjYPMW6VyG6P0BSILkKw/6uGGa9mmXCg2WGePkf1oI+OhFuX5Fr32UAAYy oWdPe8tLpwDwCudyhNkPVUIn7hZ8TpIqjab1WvE6/JcO37x8YKcdJKA/HfuSshG69728 CslwEZKm+Tfyv3wHwzdcCxkHgbdSwbx89Q8ePfl66ANdoX8mCESIcZ2w3a79d4HcQ+4n ogJS9BCizSfHzuAFtaKRRnnh3fb8vRZ4UHy4Nla+b2C68k4XMGaLe9GaMdkM/66L4irt Exjw== 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=KyjlWpygF8iBQPt2JPewFu0EYxma3wLGxqS/oi6tK9k=; b=b+ZhFSp7vPUro8TnCe5S+GxezHvGqzwO2IAMJrmzzTEYfMTD0KrBKcEXsKuSmhtqmM oJoIp/J55mRbwGbBM4UDbD6FYBeBdbSnRpJMaq+74e1fhBG5F4nG9HqhPDL4TZeDZVeY tfAZYwJM2pcuUBV6/TA2V7ZYMIFiXr2Uy9XeIGn445iUQs1pkVJ7gwvTokQUs69iuWvb PUqF+NOq5g02Kom3XiZzzJYH80gVROORxH2kWyMmz3ldD0j0wC4scQFl2cfnXlzc/6nW i39Lb4edRZwoZk4CAokehN2LyHOcZahpAkSSJ3JptyLNJuKDeq1BeOkC7Neq5ObCAuow d/VA== X-Gm-Message-State: APjAAAXGVNpRXRqvGUMVbviMnS7ofRR6eBONk16tIskxIgC2KgblF1uR fH7GSr/8Df3n0pCuHRbfsC1nkQ== X-Google-Smtp-Source: APXvYqwOeaSURpk3l2mCl6gc959XKleyQ4WKONzxER3xasc9NS95bQanS3yrR1da/ttQaZfAyJruBw== X-Received: by 2002:a92:1b59:: with SMTP id b86mr50125144ilb.84.1578256495325; Sun, 05 Jan 2020 12:34:55 -0800 (PST) Received: from [172.19.0.168] ([75.104.87.166]) by smtp.gmail.com with ESMTPSA id x13sm16427969ioj.80.2020.01.05.12.34.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jan 2020 12:34:54 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CD799C84-A2BC-419E-BBC3-74276B877F7B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Sun, 5 Jan 2020 15:34:33 -0500 In-Reply-To: Cc: Eric Rescorla , ADD Mailing list , Adam Roach To: Brian Dickson References: <06651663-3825-409E-8277-52CABC2B86ED@fugue.com> <30C0C4E0-83A8-498D-B5D5-4C73314E27D6@rfc1035.com> <138ca873-8ae4-c944-d7dc-e3dc9e635c01@nostrum.com> <080A70BB-C7D0-40FF-A1C2-BB3D5C4AF749@fugue.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 20:34:58 -0000 --Apple-Mail=_CD799C84-A2BC-419E-BBC3-74276B877F7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 5, 2020, at 3:29 PM, Brian Dickson = wrote: > Resolver discovery. Okay, but what specific problem are you trying to solve? You can = already do resolver discovery with DHCP or RA. You continued this with = a really long answer, but it was more of a description of your solution = to your unstated problem. Start with the basics. Describe a = configuration that you think makes sense. Describe why it makes sense. = Explain why just using DHCP or RA doesn=E2=80=99t work in that = configuration. --Apple-Mail=_CD799C84-A2BC-419E-BBC3-74276B877F7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 5, 2020, at 3:29 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Resolver = discovery.

Okay, but = what specific problem are you trying to solve? =   You can already do resolver discovery with DHCP or RA.  You = continued this with a really long answer, but it was more of a = description of your solution to your unstated problem.   Start with = the basics.   Describe a configuration that you think makes sense. =   Describe why it makes sense.   Explain why just using DHCP = or RA doesn=E2=80=99t work in that configuration.

= --Apple-Mail=_CD799C84-A2BC-419E-BBC3-74276B877F7B-- From nobody Sun Jan 5 13:18:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D453120089 for ; Sun, 5 Jan 2020 13:18:31 -0800 (PST) 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, 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=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 ujZRMF8G11FX for ; Sun, 5 Jan 2020 13:18:30 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 27BB1120043 for ; Sun, 5 Jan 2020 13:18:30 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id r11so25944573pgf.1 for ; Sun, 05 Jan 2020 13:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Dyij1lqsHqIvEvkLkkWbrGqb9K3dNAnyL+uMOodPjNI=; b=tY+uSeie+vwUgwiFpHhImX2+im9xGcoyq9C+O32jVW0yOkfcF9iwMdkOOvqsDT9K93 tPk2btan90QUA9zJvDOkVsEY/bVQxhzgEg34iqbLpoUM7LCICcGBWW2SE8YEb9L4ENCc ZwiY2SspMjZ0nX27qPHA+riRmVBVsmJTCf7kb9E31XT1dXynTpZxT1N+CV5M5sMJdwo+ 8PhdKckma3BBybqLaWnuSqjFuJLsU+6GL9v6j6xjT8QK9KnX8jgl24wN74fsFQFeV49d cxUN79A0vi4fpWs0KFHmJEjZbtjD0f90Mu2Oc21AQRI0EXOieQAOOuGyJHqL/+1avFRp hvRw== 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=Dyij1lqsHqIvEvkLkkWbrGqb9K3dNAnyL+uMOodPjNI=; b=VUc9Ozv+1ly9pqIfgs0szoI22qI2B7oQV4lt/0lRk0MiidaETz2dLqeEfUq7YpIY8B xe/GeYLNz4dbeA7gCQZbsr4qHLwNK4UDBLGB2psX29CqNYOf5EeGwgvxCeXT+5m/q5mP fm6rlykWTf/v5H1+ogAWRZgyW/Bl0lTE3Unm95W95+904h6pQA0m2PERC6oYEVjYBQBz WuaGpFMV523bVe8xZd17AMsACPl9irFirhgHPx2l+Dot9wQ8YdWNIpERMgugUyNBwinx c/N1jFzELYcR+Amm19KwS0kwTSmgLsMeU51cjdf/KKlq+oSW5YGzlacWsKxoOVGj/b7M Z4+w== X-Gm-Message-State: APjAAAUtttrAOBwfPBUiWUsiULkFnbeL/paV2sDiArxnVjjZMp4LL/7M lER2cIWFxvPNEy8Qotttd7K3/uNe X-Google-Smtp-Source: APXvYqykuFctPStLZYvgqwj5pkB2fWipeALCUOGPTSgG0ebk0YOCs9gkk4EqL+unF8DuH+8n2PnPdg== X-Received: by 2002:aa7:96f9:: with SMTP id i25mr107414736pfq.161.1578259109460; Sun, 05 Jan 2020 13:18:29 -0800 (PST) Received: from ?IPv6:2601:646:8800:1f50:4d37:d2ef:4c93:779a? ([2601:646:8800:1f50:4d37:d2ef:4c93:779a]) by smtp.gmail.com with ESMTPSA id k16sm21997661pje.18.2020.01.05.13.18.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Jan 2020 13:18:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-64177E8E-B189-469C-8DC3-08C294A789B8 Content-Transfer-Encoding: 7bit From: Brian Dickson Mime-Version: 1.0 (1.0) Date: Sun, 5 Jan 2020 13:18:27 -0800 Message-Id: <23077F64-2708-4898-A971-F074E0562CFE@gmail.com> References: Cc: Eric Rescorla , ADD Mailing list , Adam Roach In-Reply-To: To: Ted Lemon X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 21:18:32 -0000 --Apple-Mail-64177E8E-B189-469C-8DC3-08C294A789B8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Jan 5, 2020, at 12:34 PM, Ted Lemon wrote: >=20 > =EF=BB=BFOn Jan 5, 2020, at 3:29 PM, Brian Dickson wrote: >> Resolver discovery. >=20 > Okay, but what specific problem are you trying to solve? You can already= do resolver discovery with DHCP or RA. You continued this with a really lo= ng answer, but it was more of a description of your solution to your unstate= d problem. Start with the basics. Describe a configuration that you thin= k makes sense. Describe why it makes sense. Explain why just using DHCP o= r RA doesn=E2=80=99t work in that configuration. Discovery of non-forwarder resolver that does DoT/DoH. DoT/DoH to a forwarder is not privacy preserving if the upstream is non-loca= l and not using DoT/DoH. DHCP or RA will only return the servers they are configured to advertise, wh= ich may be (and frequently is) a forwarder. The most prevalent example would be home routers doing DHCP, implementing fo= rwarder functionality, and advertising themselves as the resolver. Many of t= hose use one of the public quad-N resolvers as forwarder target. Discovery of the quad-N resolver allows upgrade to DoT/DoH without forced su= bstitution of resolver. Use of quad-N would occur IFF said quad-N were the a= ctual forwarder target of the DHCP/RA server learned, and would not require t= he upgrade of the forwarder at all. Brian= --Apple-Mail-64177E8E-B189-469C-8DC3-08C294A789B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent from my iPhon= e

On Jan 5, 2020, at 12:= 34 PM, Ted Lemon <mellon@fugue.com> wrote:

<= blockquote type=3D"cite">
=EF=BB=BFOn Jan 5, 2020, at 3:29 PM, B= rian Dickson <brian.peter.dickson@gmail.com> wrote:
Resolver disco= very.

Okay, but what specific problem are you trying to solve?   You can a= lready do resolver discovery with DHCP or RA.  You continued this with a= really long answer, but it was more of a description of your solution to yo= ur unstated problem.   Start with the basics.   Describe a configu= ration that you think makes sense.   Describe why it makes sense.  = ; Explain why just using DHCP or RA doesn=E2=80=99t work in that configurati= on.

Discovery of non-forwarder r= esolver that does DoT/DoH.

DoT/DoH to a forwarder i= s not privacy preserving if the upstream is non-local and not using DoT/DoH.=

DHCP or RA will only return the servers they are c= onfigured to advertise, which may be (and frequently is) a forwarder.
<= div>
The most prevalent example would be home routers doing DH= CP, implementing forwarder functionality, and advertising themselves as the r= esolver. Many of those use one of the public quad-N resolvers as forwarder t= arget.

Discovery of the quad-N resolver allows upgr= ade to DoT/DoH without forced substitution of resolver. Use of quad-N would o= ccur IFF said quad-N were the actual forwarder target of the DHCP/RA server l= earned, and would not require the upgrade of the forwarder at all.

Brian
= --Apple-Mail-64177E8E-B189-469C-8DC3-08C294A789B8-- From nobody Sun Jan 5 14:39:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE58D12002F for ; Sun, 5 Jan 2020 14:39:07 -0800 (PST) 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 1OOlAX4bd0yU for ; Sun, 5 Jan 2020 14:39:06 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 A82AC120013 for ; Sun, 5 Jan 2020 14:39:05 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id a13so49055196ljm.10 for ; Sun, 05 Jan 2020 14:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KazbrII9BlJHM1J2RCbriMJYx4lfgUux8lJr5LHZ9dE=; b=U4h0X7yuR9jrgILJSru01SRVjHwAOj9mKKLhttvQLtntJ5GZBYf8xft5EwzCSnfxt3 uuwibgzqKbmYXehPqd5uM8U41NZJot4ICv2IUMwqnoqe5VfP5VPFUn/+7sXDOizTma6L 9VIBWuqwzMktm6+EAOQKojwh6EJ16dWLJHSsdJPdhW1Cw6G+lT6b1IwwOGLicM3bRKcj 20NyQJCwx8eH+q05P5uUdX4iL/stLecgdE37hWHvo4o0LR0CUAJfkx2o8K52ijIur3jH 2fq0xbSb2SYh089LoPd0k9c4G2shg2q2wgUPQe1HcerTSTtTlcolpA0Bq+hfHDGGVRmw egcw== 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=KazbrII9BlJHM1J2RCbriMJYx4lfgUux8lJr5LHZ9dE=; b=lr0MTRIXUKYIgtT910SXJ3K7yCXx/xnBQBLxQixkpYcJb0jrErtx26OGrIO5CDTmV+ GnLCvZF3pJNIvMp2bykT9AKZbeCbhX+MqA36ggHbekR+ZNabKZB7XlxTtSW6z2JpSBpU WuRyo+EtEXbnpzZMAhL94OCynvbrmq+2aPBLIOrpff+tHE/funL8tuG5EyUDtqUM+Mov Y1no60MqY5zPjKLQ4j6oUgsmdwDBHHmS1EIVEkc15q5d8Ul8wtNkJZotj8N5DTaxTP6H 5NJcIFWhCk6QfMu+nZTsVJJ0jXjTO/gFtTLuqeo9/8gC9WMN7MqgDDJNymlnoYKpcO4p v1ug== X-Gm-Message-State: APjAAAXcEanH/ySW44DYQOSk+5VFutYU969qMD070qFQ+15xmeVUkMvG sc9JUCxPbJePQ8YAq+LEfrDtzpRbo4YyQHTJY5mHVQ== X-Google-Smtp-Source: APXvYqxm0q7Xp/5hlkYkJmjIB+eo7D9aEx4/cpOxQ4y0tRmsb0Avo8K9liBVeruDB5lAiPzglblfdRqxAN6aZ8iVncY= X-Received: by 2002:a2e:3a13:: with SMTP id h19mr59288193lja.16.1578263943925; Sun, 05 Jan 2020 14:39:03 -0800 (PST) MIME-Version: 1.0 References: <23077F64-2708-4898-A971-F074E0562CFE@gmail.com> In-Reply-To: <23077F64-2708-4898-A971-F074E0562CFE@gmail.com> From: Eric Rescorla Date: Sun, 5 Jan 2020 14:38:26 -0800 Message-ID: To: Brian Dickson Cc: Ted Lemon , ADD Mailing list , Adam Roach Content-Type: multipart/alternative; boundary="000000000000bd646d059b6c3549" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 05 Jan 2020 22:39:08 -0000 --000000000000bd646d059b6c3549 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 5, 2020 at 1:18 PM Brian Dickson wrote: > > > Sent from my iPhone > > On Jan 5, 2020, at 12:34 PM, Ted Lemon wrote: > > =EF=BB=BFOn Jan 5, 2020, at 3:29 PM, Brian Dickson > wrote: > > Resolver discovery. > > > Okay, but what *specific* problem are you trying to solve? You can > already do resolver discovery with DHCP or RA. You continued this with a > really long answer, but it was more of a description of your solution to > your unstated problem. Start with the basics. Describe a configuratio= n > that you think makes sense. Describe why it makes sense. Explain why > just using DHCP or RA doesn=E2=80=99t work in that configuration. > > > Discovery of non-forwarder resolver that does DoT/DoH. > > DoT/DoH to a forwarder is not privacy preserving if the upstream is > non-local and not using DoT/DoH. > > DHCP or RA will only return the servers they are configured to advertise, > which may be (and frequently is) a forwarder. > > The most prevalent example would be home routers doing DHCP, implementing > forwarder functionality, and advertising themselves as the resolver. Many > of those use one of the public quad-N resolvers as forwarder target. > > Discovery of the quad-N resolver allows upgrade to DoT/DoH without forced > substitution of resolver. Use of quad-N would occur IFF said quad-N were > the actual forwarder target of the DHCP/RA server learned, and would not > require the upgrade of the forwarder at all. > This seems like a potentially reasonable problem statement, though as noted previously, it's not secure against many forms of active attack. However, given that the initial discovery procedure is insecure, I'm puzzled why you think that DNSSEC (or anything like it) is required. Rather, what's required is that the discovery be via DNS (so that the upstream can inject its response) but if you're interested in using the Quad-N resolvers, then the operators can quite easily acquire WebPKI certs. -Ekr --000000000000bd646d059b6c3549 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 5, 2020 at 1:18 PM Brian = Dickson <brian.peter.di= ckson@gmail.com> wrote:


Sent from my iPho= ne

On Jan 5, 2020, at 1= 2:34 PM, Ted Lemon <mellon@fugue.com> wrote:

=EF=BB=BFOn Jan 5, 2020, at 3:29 PM, Brian Dick= son <= brian.peter.dickson@gmail.com> wrote:
=
Resolver discovery.

<= /div>
Okay, but what specific=C2=A0problem are you trying to sol= ve? =C2=A0 You can already do resolver discovery with DHCP or RA.=C2=A0 You= continued this with a really long answer, but it was more of a description= of your solution to your unstated problem. =C2=A0 Start with the basics. = =C2=A0 Describe a configuration that you think makes sense. =C2=A0 Describe= why it makes sense. =C2=A0 Explain why just using DHCP or RA doesn=E2=80= =99t work in that configuration.

Discovery of non-forwarder resolver that does DoT/DoH.

DoT/DoH to a forwarder is not privacy preserving if the upstream is = non-local and not using DoT/DoH.

DHCP or RA will o= nly return the servers they are configured to advertise, which may be (and = frequently is) a forwarder.

The most prevalent exa= mple would be home routers doing DHCP, implementing forwarder functionality= , and advertising themselves as the resolver. Many of those use one of the = public quad-N resolvers as forwarder target.

Disco= very of the quad-N resolver allows upgrade to DoT/DoH without forced substi= tution of resolver. Use of quad-N would occur IFF said quad-N were the actu= al forwarder target of the DHCP/RA server learned, and would not require th= e upgrade of the forwarder at all.

<= div>This seems like a potentially reasonable problem statement, though as n= oted previously, it's not secure against many forms of active attack.

However, given that the initial discovery procedure= is insecure, I'm puzzled why you think that DNSSEC (or anything like i= t) is required. Rather, what's required is that the discovery be via DN= S (so that the upstream can inject its response) but if you're interest= ed in using the Quad-N resolvers, then the operators can quite easily acqui= re WebPKI certs.

-Ekr
--000000000000bd646d059b6c3549-- From nobody Sun Jan 5 16:32:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD41200D5 for ; Sun, 5 Jan 2020 16:32:37 -0800 (PST) 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 tykPFBN9OmHP for ; Sun, 5 Jan 2020 16:32:35 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 6EC7A1200B1 for ; Sun, 5 Jan 2020 16:32:35 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id a12so16544022uan.0 for ; Sun, 05 Jan 2020 16:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CwP1LnB5whmu8plMUoEB8EtjnMEBcQg87tZu7LPFj6Q=; b=KzL8YJRQGc+0PCsvlaqjB/9AQqonH9Wg+TqBBD1tKz3nE5eZrmqrDlaP+11PDGMx5r gvcio1URJjR5LpLvhg90Z6WrZFiYhIs0TgqPJFePx5bdo3A/vk7WntJJh5PhSdES9G2x Q0WbosWpu7iikBtgGni6o00abCm/2WAnL3y4r70i0ha95OQvWo8aNeZotk5SLPODpYMm Enp430YGeArJqs3+geai3knbWtoWUNPJJptqmSCUbMzb7g96NDpRhP9HEgPpgWRebAE1 1KtpgZnJ3mNrTzPLwuYGNzLKj98JiPBmYNlNOYM4w/bTEaSvHZiccF3TpBgeYQ/0YTAZ 2JGQ== 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=CwP1LnB5whmu8plMUoEB8EtjnMEBcQg87tZu7LPFj6Q=; b=O0f3OovaZXTsCO9phmiEnoyxc0mTPMb5167bSDAoXeVOb3AOVHG2vLVZoV2NJA0K1A 7C9K9q2YLi+aK5QfV4z3zsNVrC3vTXzdcNaC9eLTQxJY7fMgiOepvoRDL4Bmwd60oMTW 2MGwIIda7H1P2Dkhkt3tJbrPrZPldAoVBeCAkiu4DeeUYU4Bap2B1ExOOTrcwn+wW0P9 ggNQkdiV1AigK0J5kQ/6jxrMfH6sX5KSaHOb25pAnvnQezi3MH164q6yijuNPwhRf35W 197NeAl0GBB8qvmrwW6s+bP6hGZsdOzWlAGcg7pTnW+O/+y7z7J9ZCXSZMWNsNVOY0g8 xoVg== X-Gm-Message-State: APjAAAVThcdTjuezyiJJyV3IuJrYSUibcd7qxNLpPIRk4SpCNSp9jNEf CzomtjX/UjbE4vSsVlULWDcUUDIIixx8Mf0+y2c= X-Google-Smtp-Source: APXvYqzX+YQnpjSAje+8HK+4SdHDV+MxB5u26F1IUGauok2HrC/RG1czTXR/k6C5AUjGvX8cRYVboesgTErcKkMKFSI= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr49879817uaq.114.1578270754445; Sun, 05 Jan 2020 16:32:34 -0800 (PST) MIME-Version: 1.0 References: <23077F64-2708-4898-A971-F074E0562CFE@gmail.com> In-Reply-To: From: Brian Dickson Date: Sun, 5 Jan 2020 16:32:23 -0800 Message-ID: To: Eric Rescorla Cc: Ted Lemon , ADD Mailing list , Adam Roach Content-Type: multipart/alternative; boundary="000000000000ad9dea059b6dcb08" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 06 Jan 2020 00:32:37 -0000 --000000000000ad9dea059b6dcb08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 5, 2020 at 2:39 PM Eric Rescorla wrote: > > > On Sun, Jan 5, 2020 at 1:18 PM Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> >> Sent from my iPhone >> >> On Jan 5, 2020, at 12:34 PM, Ted Lemon wrote: >> >> =EF=BB=BFOn Jan 5, 2020, at 3:29 PM, Brian Dickson >> wrote: >> >> Resolver discovery. >> >> >> Okay, but what *specific* problem are you trying to solve? You can >> already do resolver discovery with DHCP or RA. You continued this with = a >> really long answer, but it was more of a description of your solution to >> your unstated problem. Start with the basics. Describe a configurati= on >> that you think makes sense. Describe why it makes sense. Explain why >> just using DHCP or RA doesn=E2=80=99t work in that configuration. >> >> >> Discovery of non-forwarder resolver that does DoT/DoH. >> >> DoT/DoH to a forwarder is not privacy preserving if the upstream is >> non-local and not using DoT/DoH. >> >> DHCP or RA will only return the servers they are configured to advertise= , >> which may be (and frequently is) a forwarder. >> >> The most prevalent example would be home routers doing DHCP, implementin= g >> forwarder functionality, and advertising themselves as the resolver. Man= y >> of those use one of the public quad-N resolvers as forwarder target. >> >> Discovery of the quad-N resolver allows upgrade to DoT/DoH without force= d >> substitution of resolver. Use of quad-N would occur IFF said quad-N were >> the actual forwarder target of the DHCP/RA server learned, and would not >> require the upgrade of the forwarder at all. >> > > This seems like a potentially reasonable problem statement, though as > noted previously, it's not secure against many forms of active attack. > > However, given that the initial discovery procedure is insecure, I'm > puzzled why you think that DNSSEC (or anything like it) is required. > Rather, what's required is that the discovery be via DNS (so that the > upstream can inject its response) but if you're interested in using the > Quad-N resolvers, then the operators can quite easily acquire WebPKI cert= s. > > It's only required if the intermediate system (forwarder doing its own discovery and serving DoH/DoT) supports DNSSEC but not the full set of CAs (or the set needed for the cert for Resolver Foo, for arbitrary value of "Foo"). The bootstrap I'm working on has two phases (very closely coupled). Learning and remembering names and trust anchors, minimizes the weakness caused by the insecurity of the first step (using a well-known name). For the case where the forwarder itself is "upgraded" (for lack of a better term), it should be possible for the forwarder to publish trust anchors both for its own name (random unique .zz name) and for the well-known name's zone. (i.e. Place the well-known name in its own zone, with a way to link from that well-known name to the unique forwarder name, and to sign that linkage by the locally instantiated well-known name's trust anchor.) Local context and local significance opens up techniques that are inappropriate and unworkable in the global namespace. I'm interested in supporting Quad-N, but not exclusively. The idea is to support same-resolver upgrades, for the largest possible set of resolvers (full resolvers rather than forwarders). There are at least hundreds of thousands of those, and possibly as many as several million (3 million is the number reported by a researcher in DNS-OARC based on an extensive multi-year study.) Certainly, I'd position it as "implementors are strongly recommended to support DNSSEC so that fallback to DNSSEC can be used if WebPKI validation cannot succeed due to lack of CA certificate matching the certificate offered, but where there is a corresponding TLSA record." I don't think exclusively depending on DNSSEC is required, but I also don't think exclusively depending on WebPKI is the best course of action for the potential WG charter. Brian > --000000000000ad9dea059b6dcb08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 5, 2020 at 2:39 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Sun, Jan 5, 2020 at 1:18 PM Brian Dickson <brian.peter.dic= kson@gmail.com> wrote:


Sent from my iPhon= e

On Jan 5, 2020, at 12= :34 PM, Ted Lemon <mellon@fugue.com> wrote:

=EF=BB=BFOn Jan 5, 2020, at 3:29 PM, Brian Dicks= on <b= rian.peter.dickson@gmail.com> wrote:
<= div>
Resolver discovery.

Okay, but what specific=C2=A0problem are you trying to solv= e? =C2=A0 You can already do resolver discovery with DHCP or RA.=C2=A0 You = continued this with a really long answer, but it was more of a description = of your solution to your unstated problem. =C2=A0 Start with the basics. = =C2=A0 Describe a configuration that you think makes sense. =C2=A0 Describe= why it makes sense. =C2=A0 Explain why just using DHCP or RA doesn=E2=80= =99t work in that configuration.

Discovery of non-forwarder resolver that does DoT/DoH.

DoT/DoH to a forwarder is not privacy preserving if the upstream is = non-local and not using DoT/DoH.

DHCP or RA will o= nly return the servers they are configured to advertise, which may be (and = frequently is) a forwarder.

The most prevalent exa= mple would be home routers doing DHCP, implementing forwarder functionality= , and advertising themselves as the resolver. Many of those use one of the = public quad-N resolvers as forwarder target.

Disco= very of the quad-N resolver allows upgrade to DoT/DoH without forced substi= tution of resolver. Use of quad-N would occur IFF said quad-N were the actu= al forwarder target of the DHCP/RA server learned, and would not require th= e upgrade of the forwarder at all.

<= div>This seems like a potentially reasonable problem statement, though as n= oted previously, it's not secure against many forms of active attack.

However, given that the initial discovery procedure= is insecure, I'm puzzled why you think that DNSSEC (or anything like i= t) is required. Rather, what's required is that the discovery be via DN= S (so that the upstream can inject its response) but if you're interest= ed in using the Quad-N resolvers, then the operators can quite easily acqui= re WebPKI certs.


It's only required if the intermediate system (forwarder doing i= ts own discovery and serving DoH/DoT) supports DNSSEC but not the full set = of CAs (or the set needed for the cert for Resolver Foo, for arbitrary valu= e of "Foo").

The bootstrap I'm worki= ng on has two phases (very closely coupled). Learning and remembering names= and trust anchors, minimizes the weakness caused by the insecurity of the = first step (using a well-known name).
For the case where the forw= arder itself is "upgraded" (for lack of a better term), it should= be possible for the forwarder to publish trust anchors both for its own na= me (random unique .zz name) and for the well-known name's zone.
(i.e. Place the well-known name in its own zone, with a way to link from= that well-known name to the unique forwarder name, and to sign that linkag= e by the locally instantiated well-known name's trust anchor.)
Local context and local significance opens up techniques that are inappro= priate and unworkable in the global namespace.=C2=A0

I'm interested in supporting Quad-N, but not exclusively. The idea i= s to support same-resolver upgrades, for the largest possible set of resolv= ers (full resolvers rather than forwarders). There are at least hundreds of= thousands of those, and possibly as many as several million (3 million is = the number reported by a researcher in DNS-OARC based on an extensive multi= -year study.)

Certainly, I'd position it as &q= uot;implementors are strongly recommended to support DNSSEC so that fallbac= k to DNSSEC can be used if WebPKI validation cannot succeed due to lack of = CA certificate matching the certificate offered, but where there is a corre= sponding TLSA record."=C2=A0

I don't thin= k exclusively depending on DNSSEC is required, but I also don't think e= xclusively depending on WebPKI is the best course of action for the potenti= al WG charter.

Brian
--000000000000ad9dea059b6dcb08-- From nobody Mon Jan 6 05:53:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6310120812 for ; Mon, 6 Jan 2020 05:53:52 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saBMq4qkSBI6 for ; Mon, 6 Jan 2020 05:53:49 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 02F001200CC for ; Mon, 6 Jan 2020 05:53:49 -0800 (PST) Received: from 200116b824355000b0b38eedb7ed3ae1.dip.versatel-1u1.de ([2001:16b8:2435:5000:b0b3:8eed:b7ed:3ae1]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ioSpF-0008U1-Lt; Mon, 06 Jan 2020 14:53:45 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Mime-Version: 1.0 (1.0) Date: Mon, 6 Jan 2020 14:53:45 +0100 Message-Id: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> Cc: Ben Schwartz , ADD Mailing list In-Reply-To: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> To: Stephen Farrell X-Mailer: iPhone Mail (17C54) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578318829;15e78427; X-HE-SMSGID: 1ioSpF-0008U1-Lt Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 06 Jan 2020 13:53:53 -0000 Hi all, I agree with Stephan in that I would prefer a more scoped charter. I see a lot of interest in the ideas around the adaptive DNS work and I thin= k we should build a charter that targets exactly that, as proposed by Tommy,= to make sure that at least this piece of concrete work can move forward (qu= ickly). Other topics/problems can go in to other existing or new working groups. Esp= ecially topics related to documenting operational practices, as mentioned be= low in the charter, we already have a working group for and these topics sho= uld be discussed that group, nann my rly dnsops (potentially leading to some= rechartering of that group in order to make clear that aspects related to o= perating and maintaining encrypted DNS traffic and DNS servers are in scope)= . Mirja > Am 04.01.2020 um 17:20 schrieb Stephen Farrell = : >=20 > =EF=BB=BF > Hiya, >=20 > The verbosity and lack of agreement and clarity on the list > since this was posted has convinced me that this is not a > viable charter. >=20 > That said, some (mostly negative, sorry;-) comments > below... >=20 > Cheers, > S. >=20 >> On 20/12/2019 15:20, Ben Schwartz wrote: >> Hello ADD list, >>=20 >> Based on the feedback from the ABCD BoF at IETF 106, and with additional >> input from chairs and area directors from relevant working groups, the AB= CD >> BoF chairs have drafted the following updated charter for a working group= . >> Please review it and share your perspective. >>=20 >> Tommy Pauly has recently posted a charter text proposal that considers >> closely related issues. This is not a competition, so please avoid =E2=80= =9Cvoting=E2=80=9D >> for one proposed text over the other. The text of any final charter will= >> be written by the IESG. To help them judge whether a working group shoul= d >> be formed, and how it should be chartered, the most productive input woul= d >> be to know which elements of each text you find valuable (if any), and >> which you would like to see changed in any final charter. >=20 > Tommy's proposal has the benefit of covering fewer topics. > I think that's (fewer topics) likely a requirement if any > progress is to be made. >=20 >>=20 >> ----------------------------------- >>=20 >> Proposed charter text: >>=20 >> This working group will focus on DNS client side topics, particularly >> discovery and selection of resolvers. This complements existing DNS-relat= ed >> working groups, which are responsible for improvements to the DNS protoco= l >> itself, and for operational questions that are principally of interest to= >> DNS server operators. >=20 > I like that you've tried to provide a logical functional > basis for what to in/exclude in the WG. However, my take > is that success/failure will be much more driven by the > non-functional aspects (e.g. cat-herding, not biting off > more than can be chewed) so I'm not sure this is needed, > even if it's clever;-) >=20 >>=20 >> The working group is chartered to develop an extensible protocol for a DN= S >> client to learn detailed information about a resolver, based on >> draft-ietf-dnsop-resolver-information, which will be transferred from >> dnsop. >=20 > Using that to discover that a recursive offers DoT/DoH > seems to provide, at best, opportunistic security. But > I like opportunistic security approaches, where they're > useful, and it could be useful here, in some networks. > In other networks and for some applications, the OS > approach will provide no substantive benefit. >=20 > For opportunistic security to be useful also needs at > least a story/plan for how to get to something better. So > I think there's a major missing part here about > re-visited networks. (Even if aspects of that are > implementation-specific, the story is needed before we > know the opportunistic staging post is useful.) >=20 > I think a wg that doesn't start out with an agreed > understanding as to whether or not discovery being > opportunistic is ok or not will fail. There may even > be a need to catalog the various possible setups and how > discovery plays out in each in order to make progress. > (Recent list discussion with unqualified uses of the > term "trust" along with ambiguous pronouns seems to > indicate that may be needed.) >=20 > Even with all that, I'm not clear what'd motivate an > application (whether a browser or something else) to want > to do this, though I can see this possibly being useful > for a system or OS stub. I could also see some applications > using this as a way to be seen to be "doing something." All > that said, the "useful" here doesn't seem like a huge win > really in many networks. (IOW, if someone thinks defining > this will stop applications using their own choices of DoH > server, my guess is that that's wishful thinking.) >=20 > I don't understand the information leakage aspects of this, if a > non-updated recursive forwards the queries upward, nor > potential attacks (on stubs, launched by/via recursives) > this might enable. (E.g. does the nxdomain for the first > a.b.c.10.in-addr.arpa mean no other e.f.g.10.in-addr.arpa > will be forwarded for the TTL?) >=20 > I'm not convinced this putative wg is the right place to > develop an extensible protocol like this - dnsop seems much > better suited really, so I'd argue to leave that draft > in dnsop. >=20 >> Relying on this new protocol where appropriate, the working group >> should produce standards-track, informational, or experimental documents >> that provide the following items, using the drafts in brackets as input >> (with no obligation to adopt them): >> * methods for a recursive resolver to advertise support for an alternativ= e >> transport protocol [draft-sah-resinfo-doh], >=20 > The security considerations of that seem to me to make it > either pointless (already doing DoT/DoH) or impossible > (DNSSEC for 10.in-addr.arpa). >=20 >> * methods for a recursive resolver to indicate that it will sometimes >> return DNS results that are different from the global DNS >> [draft-grover-add-policy-detection], >=20 > That bit seems ok, though canaries are fragile of course. > It's not clear to me that needs to be in the same WG as > the recursive discovery bits, but it could be. >=20 > I don't get why both TBD.arpa and .arpa would > need to be supported by recursive developers. ISTM one > kind of oddball qname for this stuff ought suffice for all > of the things envisaged in these drafts. >=20 >> * methods for improving user privacy by avoiding DNS queries that leak >> information or directing them to a server that will have this information= >> anyway [draft-pauly-dprive-adaptive-dns-privacy], and >=20 > I think that draft by itself (and what it implies) is > already the meat for an ambitious WG. >=20 >> * a format for describing the client=E2=80=99s DNS configuration, suitabl= e for >> diagnostics and debugging. >=20 > I'm not clear why this is needed. >=20 > Attempting all of the above is IMO way too ambitious given > the divergent interests and trust models visible in folks > postings to this list over the last 8 months. >=20 >>=20 >> Where possible, any mechanisms that specify exchange of information betwe= en >> clients and resolvers should provide the security properties expected of >> IETF protocols, e.g., confidentiality protection, integrity protection, a= nd >> authentication with strong work factor. Each specification must clearly >> indicate under what circumstances and assumptions these properties are or= >> are not provided. >=20 > I'm not sure why including that boilerplate-like text is > a good idea. >=20 >> This working group will coordinate and share WGLC announcements with the >> following working groups: dnsop, capport, dprive, dhc, and homenet. The >> working group will also coordinate with the Security Area, and will be >> assigned a security advisor. >=20 > Assigned security advisors aren't that useful I think. The > person concerned is either interested or not, if they are > they'll not be shy. If they're not, they'll not be useful. >=20 >>=20 >> P.S. One note regarding this proposal: the chairs of the doh working grou= p >> expect that doh would be closed if a new working group were chartered in >> this manner or similar. >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Mon Jan 6 07:08:02 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F66120823 for ; Mon, 6 Jan 2020 07:08:00 -0800 (PST) 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_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=aKuwmVh8; dkim=pass (2048-bit key) header.d=comcast.com header.b=fivmpKXr; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=qLOOSHRL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoSN33lvnM7U for ; Mon, 6 Jan 2020 07:07:59 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 84EA412004C for ; Mon, 6 Jan 2020 07:07:59 -0800 (PST) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 006F68g4020683 for ; Mon, 6 Jan 2020 10:07:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=XyNHjBJ+RIjg3sT2iIKdss4igQFO5/gR3FnUMM+U2UA=; b=aKuwmVh8qVtW8oNuu5Pccixj/dlYXa0uRBxjPg3YzJN5RcAvspEpiKmQqKeVi4miOIkr tRl5q6hyrujPXMzLw6h4rmVIzE31NmWV4cB3jBMisppGx2Quf2gzNl5jEmLUxBQHnk4C 3w4Rxh3ewKla9lAOrCJvlGXCguadnrH32l0wlEJ9SZ2l3SKA4Ngj76BIcpQGBACeJ9Rp F34UrHuVlhCf6yNomvV5EOu7cqJtUEZQGi4oEfyYiNxoW1Nf3u6OXGWsL7UpXWweoEOO OmGaNA51WsPakGwckNuc5GmyzH9ORPvY7MN6RlX/Bio3LI/ZbyD8+5nDX1G8K6xLQ/8V dw== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2xamw6hbh4-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 06 Jan 2020 10:07:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578323278; x=2442236878; 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=XyNHjBJ+RIjg3sT2iIKdss4igQFO5/gR3FnUMM+U2UA=; b=fivmpKXr08Gsn4oUszC1Lyn5BBZqAql/qAqbCACfqS8RWknkiBfIscEUkDDnVDiN dvO6pYTjAUNxps7KAhSGi7Idpq2TEflSZvFcRnzZmrJR5YJfx0vy2wR0vx5Z79+d tz6kHrIcNFpVs+4EXP3B1CpGP7+pfe/XckyoQBPzamMk9L1zlAsmrhMjZ7AoO55u x4kQ06ahtR31h1/80KWXDaKKSJK8+aFjy+ygEqYSYa4vzOShNVDdO2/F618OmQca GlTVq7t8wHMnWbO/PAi8t2CYQcEzZyTPa2rbHWdxh79j0T3UxqbS7s88GPfFH7f6 TqhxrDLgN8fcKTtb1GrVpw==; X-AuditID: 60729ed4-24fff7000000bc72-de-5e134d4e226a Received: from COPDCEX49.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 FE.E0.48242.E4D431E5; Mon, 6 Jan 2020 08:07:58 -0700 (MST) Received: from COPDCEX11.cable.comcast.com (147.191.124.142) by COPDCEX49.cable.comcast.com (147.191.125.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 08:07:57 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX11.cable.comcast.com (147.191.124.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 08:07:57 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.172) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 10:07:48 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2324.namprd11.prod.outlook.com (10.173.204.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Mon, 6 Jan 2020 15:07:47 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 15:07:47 +0000 From: "Livingood, Jason" To: "sthaug@nethelp.no" , "add@ietf.org" Thread-Topic: [Add] Data sharing can not be detected with open resolvers Thread-Index: AQHVwgFmSQoIDAY8rkWiWFzpMh8TZ6fYkDSAgAAc5ICAAHSBAIAETK0A Date: Mon, 6 Jan 2020 15:07:47 +0000 Message-ID: References: <8AB8F976-72AB-419E-8CED-D0ED6AA6E8E1@fl1ger.de> <20200103.103119.307223552.sthaug@nethelp.no> <41DAEB3C-B97B-497D-A7A7-1C0585487747@fugue.com> In-Reply-To: <41DAEB3C-B97B-497D-A7A7-1C0585487747@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:15e3:f880:d123:10b8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35e9f5bb-369b-4022-2eb7-08d792ba3095 x-ms-traffictypediagnostic: BN6PR1101MB2324: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(376002)(39860400002)(396003)(189003)(199004)(71200400001)(33656002)(4744005)(6486002)(2616005)(316002)(5660300002)(86362001)(8936002)(110136005)(186003)(2906002)(66476007)(66556008)(64756008)(66446008)(81166006)(81156014)(66946007)(8676002)(6512007)(76116006)(6506007)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2324; H:BN6PR1101MB2195.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: J7OW19U+4F21DsjgQOcP+KxoDp+7uk1sS/9N1D0vRg+375BDwA0rAhUju+3Mr5ZW92xAq1AJXkTZheNkDc/YSs4dRcNI3uv+12E5BohzoFxU7UrZKHNPpNAx1vsH3nmQhmExhOSSLWCR+Nv8EFwhgry/dwIMV2CVxydkdBPS8HFVF3wDNiUDULy8MdnNH1D2jSmj74ydy+Db+F2QhUgtmaRn49d0vFvKLGuT96kO7NzgT8CS3GvfDIf3a50vyNrggrmhAzw7ri5Al2ph/O6Zj/KYgTy6Ly+vyZAhUija8E+ltm8KNzWkkIEs2tmoB0VSVP94jQctp7qvScBJVPANTEfr8P8Fr6m0bh37uz6F1NlnzNIZ2EbonVcj6haKneXxOm8UQE90FyX5leC56y8mzxLSMd3Wq8a75QLg0j55NqTRBrvv5F49JNKch55CbAeV x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m8WQFGBf84CAtG4XNR7a0ZiKpkUz2AODBzG7yN90Aih14VhAEBBlHtO0JBCC5iIEWQbQB+ErckAvs0gYm308I18KgLrW6KNLRojt3q7aiDPNd1UenrWO/ncmHfcBa4qXAwbVHe0Hj0rvvhLplfDNTUpOOl0vvbwv9sqbt4DQ5o3u7AOz00LM+6lCYr7H1cVA2svG8RS54MYS0ol4aqHAjwf/j6muq/st92h+qKCnIW0VUG9oYyJuCNJkcFLSnNUuQ98t4JTiK7tCc9ZLH/X1WibbPDKUv4ky/n5cAZU/h1T/uTWhsR9nRA7u35vyMLusGx84oFey7OhRF2epymWiFg== 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=r/i/L/mJpYnTjLM4kTDikDqP8qz/j+kEb583nFAYLnw=; b=YRDtuuTxXKdKBWg3LguDcEHuPTbsSArXpAdOGjuVDQqz+KyBzNQz1pGI/x/coMTkcocKGcAtbHr10WvGya2hT8ahmb0tZ/eRJWP3et/OjOgJdsXYk4rKnECEXONFq6+QGzKzcPkIxdSVoEZXqLV4KgyVfhhqPkx4igpLqXj2wAYXSucnYzq+kH584UdmoXZmwAlXQajMU/4GUOEL/urbZFgEato+FHXP4gUaN1ZSYRObzWP46TdMDuEndFzE/mN67udYhNETLVzTtDqZmo324RQDm31QT5bAvXTK1prDuCs/79IOv+ljdThrn9B67O+cuKm2m6/R4AI7Cs3sVRYeJg== 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=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r/i/L/mJpYnTjLM4kTDikDqP8qz/j+kEb583nFAYLnw=; b=qLOOSHRLOdYPmk9DQDzJCseWGXp5MIp56jAL2MxK9VUCx8pRBL5A0jJp4NMa8Q+Z7WL0WdZfGN27o6qGpOlnt6NSIkg3ATtIZdh5/egbagkCCyw+lEWnhC6M3XGSJyhSRxMIqZq8apNip4Ec/C2w18Y5qdL5udww0R7g9Q3h5s8= x-ms-exchange-crosstenant-network-message-id: 35e9f5bb-369b-4022-2eb7-08d792ba3095 x-ms-exchange-crosstenant-originalarrivaltime: 06 Jan 2020 15:07:47.1250 (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: LmydQqpOygLfQydh6y8io/b/8a7FtWwhozJOlfy5YILG7gzX8as98daz1TH/WbcBoS/u5e0pA2KMxhGjhMUNR1VLaVVg59SeTZMYZt9XIts= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2324 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <363FF3CBF8C33F4F8396B143C2FE015D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHKsWRmVeSWpSXmKPExsWSUDRnsq6fr3CcweNJahb/T69js5i3+DCT A5PHkiU/mTxmfV7CFsAU1cBoU5JRlJpY4pKalppXnGrHpYABbJJS0/KLUl0Ti3Iqg1JzUhOx KwOpTEnNySxLLdLHaow+VnMSupgydrXtZCnYxlqx9cde1gbGJaxdjJwcEgImEhdObGPuYuTi EBI4zCTxasoxJgjnIKPEls2rwaqEBG4zSly4nA6ROMEocefqKTYIZzqTxJG9vxghnIeMEl+O dbGBtLAJmEncXXiFGcQWEfCS+DThPjuILSzgLrHyzh2ouIfEx1u9bBC2m8TzuUtYuhg5OFgE VCSmr9cHCfMKuEhsWLqHHWL+WiaJ8wfbWUASnAK2Esv6J4HNYRQQk/h+ag0TiM0sIC5x68l8 JojnBCSW7DnPDGGLSrx8/A/sHVEBfYlnN3ewQPSmSCzuWgRVbyHxsOUJO4QtK3FpfjcjhO0r cXvNc3aQ2yQEdCSmn4MamS9xf8lmNghbTWLxld0sECUyEvd2g50sIfCOWeJB5zKwuJBAlsTb q3YQ5XISq3ofskxgNJmF5OhZQFXMApoS63fpQ4Q9JPa//MIMYStKTOl+yD4LHCiCEidnPmFZ wMi6ipHP0kzP0NBEz9DUQs/I0GgTIzhVzruyg/HydI9DjAIcjEo8vG/NheOEWBPLiitzDzFK cDArifA2ugnGCfGmJFZWpRblxxeV5qQWH2KU5mBREudls/0VKySQnliSmp2aWpBaBJNl4uCU amDUYZtXPndLywPBhG3Nc0WDUwtY2hfckvDLPSLS8mu+3WH5vp6mfoG43Anx8rY7hT4ofTJ5 a/BISTfy2KR4o6WSWqLl/m9bj//5rb9bWzJwp1bPpJC/Rcu/e3Lk6pj1X/SacJ3t3OmbMvK3 Gp7aL9+16dniGzcVvj6rf/+y9MLNmNVmiq1NWclKLMUZiYZazEXFiQADR+8wkQMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-06_04:2020-01-06,2020-01-06 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Data sharing can not be detected with open resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 15:08:01 -0000 PiBUaGlzIGlzIGEgdm9sdW50YXJ5IGFncmVlbWVudCBhbmQgYXMgc3VjaCBpcyBub3QgY292ZXJl ZCBieSAicmVxdWlyZWQgYnkgbGF3Ii4NCg0KW0pMXSBJbiBtYW55IGxlZ2FsIHZlbnVlcywgdGhp cyBpcyB3aHkgY29udHJhY3RzIG9mdGVuIGhhdmUgdGhlIGNsYXVzZSAiYXMgcmVxdWlyZWQgYnkg b3IgYXV0aG9yaXplZCB1bmRlciB0aGUgbGF3IiByYXRoZXIgdGhhbiBqdXN0ICJhcyByZXF1aXJl ZCBieSBsYXciLiBCdXQgZm9yIElTUHMsIHVzdWFsbHkgdGhlIGNvbmNlcm4gaXMgc3BlY2lmaWMg dG8gYSBwYXJ0aWN1bGFyIGxhdyAoZS5nLiBTdGF0dXRlIFhZWiwgU2VjdGlvbiAxLCBQYXJ0IDcp IGFuZCBzbyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgZXhjbHVzaXZlIGxhbmd1YWdlIChyZXF1aXJl ZCBieSkgaXMgdG8gYWRkIGluIHNwZWNpZmljIGxhd3Mgd2l0aCB3aGljaCBhbiBvcmdhbml6YXRp b24gbWF5IG5lZWQgdG8gY29tcGx5LiBCdXQgaXRzIGNvbXBsaWNhdGVkLi4uDQoNCg== From nobody Wed Jan 8 04:09:47 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F26120073 for ; Wed, 8 Jan 2020 04:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.334 X-Spam-Level: * X-Spam-Status: No, score=1.334 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_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9Fmz2qSeRTtN for ; Wed, 8 Jan 2020 04:09:45 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20613.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::613]) (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 0A9F5120019 for ; Wed, 8 Jan 2020 04:09:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ydjlk66/Joxdv69Vy75hm0cM3JX594YPQVr6eUGIjgLsdWY1YbbcZP5vRrhtumGGfr99l+XdvzupNaNGliOWK9rNx19aQjPyNK3qiZk7cswXwf+5TP7hSmLN4mJyuRCKKrf0io1rYf0HGfvceBBEXzTmovzoIdhn/VHft3t4GKfC8gCiQCvXIJ+we6x6H4ACVcC3SSaCzKKmsewJNcW2mupNvfxbLkaYzV4oCqzt+OJq8T7mlI9HXKOrFYReDOCwXPQUyzG28qyyZjg64kDpF4G8v/M45m4kT8o3VRnLwIAeRY4VNtLeguDGSIPWzYsRr0MPC+4yCIctFcYLhV/SVg== 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=f3wjpuY/VghdP2yhXUzPkbUZtSoY70s3TLv6jriMS1g=; b=CbGEkAhJEUnsYVN4WkJr8FSQRqzLbP1+26LmQSmPYlo2zO0O/MvgA43842wlHs9691m44TBLZyIg7+IOGp2kqG7XBLHhywT53KwBLWlnhvW1cLJJRkKcrkC268fYGmUYg1lLq8yi1uJpJt2L1WeQmx0dSRo9NQYFqqRucCwCDsNMVHrk/bTmDidwQojS9n0PdTgIwWeXLBDTeJSAfVUAZZQKCoAz6inXf8N9H8OA1hzEVlsbxcylqUxqKewzQE39iPoCJ5v0E27FnsRZEFD3yD1skFRkpbn3B80L1JPEAJDiPDmTlzilabKDOZgC4JTYGpzHXUBBGb0konLPNmsxNw== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f3wjpuY/VghdP2yhXUzPkbUZtSoY70s3TLv6jriMS1g=; b=OlvnYPCm1sGqE3HeNbPzJDD9mDG42UK0Agb5NRn6ydDNMKfOIk0XMQfyP0szAxGbmPGi6BFIC7lj+97VwvKgblx51iFVTmNX0mM141Tq7G+VNP668Mg7OpaQy+R/WrktncTt5yfzeeWCehH1Zy+SV0Hu3i98WlroDUIs+pt91EU= Received: from DB7PR06MB5868.eurprd06.prod.outlook.com (20.178.104.85) by DB7PR06MB6053.eurprd06.prod.outlook.com (20.177.193.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 12:09:42 +0000 Received: from DB7PR06MB5868.eurprd06.prod.outlook.com ([fe80::a85b:f653:a6f6:170f]) by DB7PR06MB5868.eurprd06.prod.outlook.com ([fe80::a85b:f653:a6f6:170f%6]) with mapi id 15.20.2602.016; Wed, 8 Jan 2020 12:09:42 +0000 From: "Dixon, Hugh" To: "add@ietf.org" Thread-Topic: [Add] Voluntary agreements vs laws Thread-Index: AQHVxhyCZPI1pEC+jEqTRFASWaPdfw== Date: Wed, 8 Jan 2020 12:09:42 +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.21.0.200104 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hugh.Dixon@sky.uk; x-originating-ip: [90.216.150.208] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a9fdfd3-fe42-4717-ef82-08d79433a4d8 x-ms-traffictypediagnostic: DB7PR06MB6053: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(366004)(376002)(136003)(199004)(189003)(2616005)(66446008)(66556008)(66946007)(86362001)(6506007)(5660300002)(186003)(64756008)(66476007)(6916009)(26005)(76116006)(91956017)(71200400001)(2906002)(6512007)(36756003)(316002)(6486002)(8676002)(81166006)(81156014)(8936002)(478600001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR06MB6053; H:DB7PR06MB5868.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: 2K7UtmhSPHlOjue9LKxgcTPkPrIOx5wUR/E7qh5EchJTs7RawgxuptVvxZGBpHeDLS1VChuX++fVIsd884a4EmRsXufLWKB0v/Y3/BLH4cnlDoYOxRzdhSie/ACDQwZhUIsrFeUKjF0TAr3QenTMoxIWzRYxMoJXoVgd5+bnhZu9eA7xKVXMf9kHyFrvWZITKCj5/ldl5YjaX/wxYbZkXpSZNmbQVG1Zd4oGgmedxSHzpRZGGNkxIwm2Zb/Jb0QUPPOxizAvrn4nNtFHgmgGFBkKq6Hvv4HE7SG4O6Tumolc/mBQ1vBrE/+aOIQQa0cZB2VBv3wP7ws2wAINSNrI0RMWYGfJigfGh3iwF4ISROO+OMc400r2SA1jgYBs/WAeaGn6oITKSy/9uzpQAiJTFGkIRoz+OzEFZANRULuH2fqk7qwyHOWv3NEFeflyr54/ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 4a9fdfd3-fe42-4717-ef82-08d79433a4d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 12:09:42.5058 (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: q397OWN2kRHm4n9ZmNmKVIX2gsrV7CZbGZt5ulTrBa3dyGinCY/mpiWb1SPEVrlVvLoAtX4TwidoS2hngxT7oA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR06MB6053 Archived-At: Subject: Re: [Add] Voluntary agreements vs laws X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 12:09:47 -0000 VHdvIHNpZ25pZmljYW50IGFkdmFudGFnZXMgb2YgYWdyZWVtZW50cyBpbiB0ZWNobmljYWwgZG9t YWlucyAodGhhdCByZWxhdGUgdG8gd2lkZWx5LXNvY2lhbGx5LWVuZG9yc2VkIHBvaW50cyBvZiB2 aWV3IHN1Y2ggYXMgdGhlIGJhZG5lc3Mgb2YgY2hpbGQgc2V4dWFsIGFidXNlIGltYWdlIGNvbnRl bnQgYXQgbGVhc3QpIGFzIG9wcG9zZWQgdG8gbGF3cyBpcyB0aGF0IHRoZXkgY2FuIGJlIHJlbGF0 aXZlbHkgcmFwaWRseSBtb2RpZmllZCB2aWEgbGFyZ2VseSB0ZWNobmljYWwgY29uc2Vuc3VzIGFz IHRlY2hub2xvZ3kgY2hhbmdlcyBhbmQgc2Vjb25kbHkgZG9uJ3QgaGF2ZSB0byBiZSBzdWJqZWN0 ZWQgdG8gdGhlIGludGVycHJldGF0aW9uIG9mIGEgKG9mdGVuIGhpZ2hseSBub24tdGVjaG5pY2Fs KSBqdWRnZSBpbiBvcmRlciB0byBiZSBlc3RhYmxpc2hlZCBhcyBwcmVjZWRlbnQuICBBIGNhc2Ug aW4gcG9pbnQgaXMgdGhlIGNvcHlyaWdodCBibG9ja2luZyBsZWdpc2xhdGlvbiB3aGVyZSBpbiBv cmRlciB0byBiZSBhY3R1YWxseSBlZmZlY3RpdmUgYXMgYW4gZW5mb3JjZWFibGUgbGF3LCB0aGUg d29yZGluZyBvZiB0aGUgYWN0IGFuZCBlc3BlY2lhbGx5IHRoZSBsZWdhbCBqdWRnZW1lbnQgaGFu ZGVkIGRvd24gaW4gdGVzdCBjYXNlcyBoYXMgYSBidW5jaCBvZiBzdHVmZiB0aGF0IHRvb2sgYSBs b3Qgb2YgZWZmb3J0IHRvIGdldCBldmVuIGNsb3NlIHRvIGFjdHVhbGx5IHNhbmUsIGFuZCBjYW4n dCBiZSBjaGFuZ2VkIG9yIHVwZGF0ZWQgd2l0aG91dCBhbm90aGVyIHRlc3QgY2FzZS4NCg0KT3Ig dG8gcXVvdGU7ICJIYXJkIGNhc2VzIG1ha2UgYmFkIGxhdyIgLSBhbmQgdGhlc2Ugc29ydHMgb2Yg dGhpbmdzIGFyZSBvZnRlbiBoYXJkIGNhc2VzLg0KDQpJZGVhbGx5IHRoZSBUUlIgcG9saWN5IHdv dWxkIGZpbmQgYSB3YXkgdG8gcmVjb2duaXNlIHRoaXMgY29udGV4dCBpbiBhIHdheSB0aGF0IHVz ZXJzIHdvdWxkIGNvbnNpZGVyIGRlc2lyYWJsZSBhbmQgYXBwcm9wcmlhdGUuDQpIDQoNCu+7v09u IDA2LzAxLzIwMjAsIDE1OjA4LCAiQWRkIG9uIGJlaGFsZiBvZiBMaXZpbmdvb2QsIEphc29uIiA8 YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIEphc29uX0xpdmluZ29vZEBjb21jYXN0 LmNvbT4gd3JvdGU6DQoNCiAgICA+IFRoaXMgaXMgYSB2b2x1bnRhcnkgYWdyZWVtZW50IGFuZCBh cyBzdWNoIGlzIG5vdCBjb3ZlcmVkIGJ5ICJyZXF1aXJlZCBieSBsYXciLg0KDQogICAgW0pMXSBJ biBtYW55IGxlZ2FsIHZlbnVlcywgdGhpcyBpcyB3aHkgY29udHJhY3RzIG9mdGVuIGhhdmUgdGhl IGNsYXVzZSAiYXMgcmVxdWlyZWQgYnkgb3IgYXV0aG9yaXplZCB1bmRlciB0aGUgbGF3IiByYXRo ZXIgdGhhbiBqdXN0ICJhcyByZXF1aXJlZCBieSBsYXciLiBCdXQgZm9yIElTUHMsIHVzdWFsbHkg dGhlIGNvbmNlcm4gaXMgc3BlY2lmaWMgdG8gYSBwYXJ0aWN1bGFyIGxhdyAoZS5nLiBTdGF0dXRl IFhZWiwgU2VjdGlvbiAxLCBQYXJ0IDcpIGFuZCBzbyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgZXhj bHVzaXZlIGxhbmd1YWdlIChyZXF1aXJlZCBieSkgaXMgdG8gYWRkIGluIHNwZWNpZmljIGxhd3Mg d2l0aCB3aGljaCBhbiBvcmdhbml6YXRpb24gbWF5IG5lZWQgdG8gY29tcGx5LiBCdXQgaXRzIGNv bXBsaWNhdGVkLi4uDQoNCg0KDQpJbmZvcm1hdGlvbiBpbiB0aGlzIGVtYWlsIGluY2x1ZGluZyBh bnkgYXR0YWNobWVudHMgbWF5IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50 ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIHRoZSBhZGRyZXNzZWUuIFRoZSB2aWV3cyBleHByZXNzZWQg bWF5IG5vdCBiZSBvZmZpY2lhbCBwb2xpY3ksIGJ1dCB0aGUgcGVyc29uYWwgdmlld3Mgb2YgdGhl IG9yaWdpbmF0b3IuIElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBz eXN0ZW0uIFlvdSBzaG91bGQgbm90IHJlcHJvZHVjZSwgZGlzdHJpYnV0ZSwgc3RvcmUsIHJldHJh bnNtaXQsIHVzZSBvciBkaXNjbG9zZSBpdHMgY29udGVudHMgdG8gYW55b25lLiBQbGVhc2Ugbm90 ZSB3ZSByZXNlcnZlIHRoZSByaWdodCB0byBtb25pdG9yIGFsbCBlLW1haWwgY29tbXVuaWNhdGlv biB0aHJvdWdoIG91ciBpbnRlcm5hbCBhbmQgZXh0ZXJuYWwgbmV0d29ya3MuIFNLWSBhbmQgdGhl IFNLWSBtYXJrcyBhcmUgdHJhZGVtYXJrcyBvZiBTa3kgTGltaXRlZCBhbmQgU2t5IEludGVybmF0 aW9uYWwgQUcgYW5kIGFyZSB1c2VkIHVuZGVyIGxpY2VuY2UuDQoNClNreSBVSyBMaW1pdGVkIChS ZWdpc3RyYXRpb24gTm8uIDI5MDY5OTEpLCBTa3ktSW4tSG9tZSBTZXJ2aWNlIExpbWl0ZWQgKFJl Z2lzdHJhdGlvbiBOby4gMjA2NzA3NSksIFNreSBTdWJzY3JpYmVycyBTZXJ2aWNlcyBMaW1pdGVk IChSZWdpc3RyYXRpb24gTm8uIDIzNDAxNTApIGFuZCBTa3kgQ1AgTGltaXRlZCAoUmVnaXN0cmF0 aW9uIE5vLiA5NTEzMjU5KSBhcmUgZGlyZWN0IG9yIGluZGlyZWN0IHN1YnNpZGlhcmllcyBvZiBT a3kgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMjQ3NzM1KS4gQWxsIG9mIHRoZSBjb21wYW5p ZXMgbWVudGlvbmVkIGluIHRoaXMgcGFyYWdyYXBoIGFyZSBpbmNvcnBvcmF0ZWQgaW4gRW5nbGFu ZCBhbmQgV2FsZXMgYW5kIHNoYXJlIHRoZSBzYW1lIHJlZ2lzdGVyZWQgb2ZmaWNlIGF0IEdyYW50 IFdheSwgSXNsZXdvcnRoLCBNaWRkbGVzZXggVFc3IDVRRA0K From nobody Wed Jan 8 05:07:05 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C097120816 for ; Wed, 8 Jan 2020 05:07:03 -0800 (PST) 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 f73QfGCFlfiU for ; Wed, 8 Jan 2020 05:07:01 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2D11202DD for ; Wed, 8 Jan 2020 05:07:01 -0800 (PST) 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 BA1576A257; Wed, 8 Jan 2020 14:06:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578488818; bh=L6ui6pTgGC0UR8TxsAxUYu3FaD435R934fXPemFkGn4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=YkCrnHw7qmxQ9C4B6lg0mdxdhFsw8YsVuE1+B69Sn/xW4ni7Wg4fy/01HY51yR2oL B732PYq4nR2G5CSNUl53uM8avSO4/ZqSs27fQoIauovyYWzKWZHk3o+45AAEVPrlVi cgMgtFRLs2jGyCuaBkupLh7LhJwQ5uMORPor/OTv1x9fOk5lRI9hCkGXhUT95gQ5Pi FQA0zNaDIm0cyws8jE2GTTy/K8ffA52ZCxvp8pgPn8pJPHgjxFJwltozMA+JOxmqtR wrRBxc8vj8zOYvvO7+eWhD4MMAF16qPflg5DcueK5kyDvR8+nfPs+gOH5Tb+CP/AW0 ORfJXGaU38kmQ== 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 AD62F3C015B; Wed, 8 Jan 2020 14:06:58 +0100 (CET) Date: Wed, 8 Jan 2020 14:06:58 +0100 (CET) From: Vittorio Bertola To: =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= , Stephen Farrell Cc: ADD Mailing list Message-ID: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> In-Reply-To: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> 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.3-Rev3 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] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 13:07:03 -0000 > Il 06/01/2020 14:53 Mirja K=C3=BChlewind (IETF) ha = scritto: >=20 > I agree with Stephan in that I would prefer a more scoped charter. >=20 > I see a lot of interest in the ideas around the adaptive DNS work and I t= hink we should build a charter that targets exactly that, as proposed by To= mmy, to make sure that at least this piece of concrete work can move forwar= d (quickly). I really disagree with this idea. The release and early deployment of DoH o= pened up many non-technical issues that need a few missing technical pieces= to be addressed, starting from a resolver discovery and selection mechanis= m that makes it possible to deploy encrypted DNS within the existing networ= k architectures, without changing the resolver operator and without requiri= ng the operator to be vetted by a third party. It would be kind for the IET= F to work on that as soon as possible and show to the other stakeholders th= at it cares about all the complaints that have been publicly made for the l= ast ~18 months. Not doing that, and rather working on yet more technology that exacerbates = the issues by disrupting more of the existing DNS and network architectures= , would IMHO not be a very constructive course of action. --=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 Wed Jan 8 05:21:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAF21200F7 for ; Wed, 8 Jan 2020 05:21:26 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 Ksf42lUF60P2 for ; Wed, 8 Jan 2020 05:21:24 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3B41F1200B7 for ; Wed, 8 Jan 2020 05:21:24 -0800 (PST) Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipBGz-0008FY-QF; Wed, 08 Jan 2020 14:21:21 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind X-Priority: 3 In-Reply-To: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> Date: Wed, 8 Jan 2020 14:21:21 +0100 Cc: Stephen Farrell , ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578489684;fb57c6d5; X-HE-SMSGID: 1ipBGz-0008FY-QF Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 13:21:26 -0000 Hi Vittorio, The charter proposed by Tommy (see [1]) is exactly focusing on discovery = and selection. What are you missing there? Mirja [1] = https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w > On 8. Jan 2020, at 14:06, Vittorio Bertola = wrote: >=20 >=20 >> Il 06/01/2020 14:53 Mirja K=C3=BChlewind (IETF) = ha scritto: >>=20 >> I agree with Stephan in that I would prefer a more scoped charter. >>=20 >> I see a lot of interest in the ideas around the adaptive DNS work and = I think we should build a charter that targets exactly that, as proposed = by Tommy, to make sure that at least this piece of concrete work can = move forward (quickly). >=20 > I really disagree with this idea. The release and early deployment of = DoH opened up many non-technical issues that need a few missing = technical pieces to be addressed, starting from a resolver discovery and = selection mechanism that makes it possible to deploy encrypted DNS = within the existing network architectures, without changing the resolver = operator and without requiring the operator to be vetted by a third = party. It would be kind for the IETF to work on that as soon as possible = and show to the other stakeholders that it cares about all the = complaints that have been publicly made for the last ~18 months. >=20 > Not doing that, and rather working on yet more technology that = exacerbates the issues by disrupting more of the existing DNS and = network architectures, would IMHO not be a very constructive course of = action. >=20 > --=20 >=20 > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com=20 > Office @ Via Treviso 12, 10144 Torino, Italy >=20 From nobody Wed Jan 8 05:23:13 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B3612021D for ; Wed, 8 Jan 2020 05:23:11 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MX2Vp2kMIAib for ; Wed, 8 Jan 2020 05:23:09 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 A05861200F4 for ; Wed, 8 Jan 2020 05:23:09 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id g6so1137017plt.2 for ; Wed, 08 Jan 2020 05:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=x89BpOlOmL40qfM3rjYJlnBu40lkMB7/n8doDVB4gTs=; b=VzNq/K8+MwbwtwvW9jCvo/Dqj5ZZEW7+7xivtTezMY7fHj4HDJe2m8RaLO+oJOguws RqwtIgkE2tJFcWKfyVOCA8aEhLnoIRDaFaIBrv0hqQpVoObb7Fx6Mn33Vfd6k754JNKJ edP08tAyn8zCDeMv2WW6jV4SdWmdHbNO0k+SAnHPRkldtRarQ6ZlHzWk/HpkS8WHt5tS m1NEFfMBgTiR+/Y8ioj5GXzXKWfS8lZtyyiDgqJD1nMP9l6KG+3nrjSCf5qJJp1jixHn 4TNL9arMpduND5KtaasZ5+ArXpYPz0O1Au+2VCOFVBhMLBPTmROBn0GhNpm1Eg2qsjeX a+Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=x89BpOlOmL40qfM3rjYJlnBu40lkMB7/n8doDVB4gTs=; b=Lz6t/nq2jS2T78a1ywEd/ENQrGf7rf58Qn4znllWrqjVqsUnSieKjNxCJBRJWuvbHe A8upbJ0pO84R5p2P8g7B74bg+58YmjK3xJHiagdaT7hg816KKBF1cg2FJiJowuZbo/tW Nh7QBE9vuTQvJSdGxn25pceQRIRxMC8b/NiGf+vJ+iyTBITfCmBxJALHFqIQa0C8laJP ZbWhm3NF8gjmprF5xiDW1MjRl/N66hUV9QYm8EJzmPb4AcrOT769xYxTqjOtQWD9k7z2 RAboFLJ63i0COCVUnqwPOapUCGQpQIlvixG3+nbzk1N2SkuWNEk84oudFjEOiE+8Rcxp wmLA== X-Gm-Message-State: APjAAAWd3z8NxYTu34z/eMJ+NNpg/5EBXSbue9ueZCmrpNoLc4nT80ou eTrRE5bNa7wnXU0jZOZpk2fEKQ== X-Google-Smtp-Source: APXvYqwWctBXGgVdSdClFT34siWruWULL1OlRtwXGwMDvkhEwqI9euz9mTj8SSy6dTOiTJCJ0/kcGw== X-Received: by 2002:a17:902:bd46:: with SMTP id b6mr5290339plx.239.1578489789095; Wed, 08 Jan 2020 05:23:09 -0800 (PST) Received: from [10.20.3.28] ([12.217.162.130]) by smtp.gmail.com with ESMTPSA id r66sm3919621pfc.74.2020.01.08.05.23.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 05:23:08 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B742AEB0-78D8-4D7E-90FC-E21BF72C06AF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) From: Ted Lemon X-Priority: 3 In-Reply-To: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> Date: Wed, 8 Jan 2020 05:23:07 -0800 Cc: =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= , Stephen Farrell , ADD Mailing list Message-Id: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 13:23:12 -0000 --Apple-Mail=_B742AEB0-78D8-4D7E-90FC-E21BF72C06AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 8, 2020, at 5:06 AM, Vittorio Bertola = wrote: > The release and early deployment of DoH opened up many non-technical = issues that need a few missing technical pieces to be addressed, = starting from a resolver discovery and selection mechanism that makes it = possible to deploy encrypted DNS within the existing network = architectures, without changing the resolver operator and without = requiring the operator to be vetted by a third party. In order to address this problem, the operator of a host using this = mechanism would need to explicitly configure a trust relationship with = the operator. Are you okay with that being part of the solution? --Apple-Mail=_B742AEB0-78D8-4D7E-90FC-E21BF72C06AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 8, 2020, at 5:06 AM, Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> = wrote:
The release = and early deployment of DoH opened up many non-technical issues that = need a few missing technical pieces to be addressed, starting from a = resolver discovery and selection mechanism that makes it possible to = deploy encrypted DNS within the existing network architectures, without = changing the resolver operator and without requiring the operator to be = vetted by a third party.

In order to address this = problem, the operator of a host using this mechanism would need to = explicitly configure a trust relationship with the operator.   Are = you okay with that being part of the solution?

= --Apple-Mail=_B742AEB0-78D8-4D7E-90FC-E21BF72C06AF-- From nobody Wed Jan 8 06:17:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9912004C for ; Wed, 8 Jan 2020 06:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRPTzyPAY5tD for ; Wed, 8 Jan 2020 06:17:15 -0800 (PST) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 554F112008D for ; Wed, 8 Jan 2020 06:17:14 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 7C24B5F40E2E; Wed, 8 Jan 2020 15:17:13 +0100 (CET) Received: from [172.19.176.164] (p54B8AF9C.dip0.t-ipconnect.de [84.184.175.156]) (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 6FA055F40A5C; Wed, 8 Jan 2020 15:17:12 +0100 (CET) From: "Ralf Weber" To: "Ted Lemon" Cc: "Vittorio Bertola" , "ADD Mailing list" , "Mirja =?utf-8?q?K=C3=BChlewind?=" , "Stephen Farrell" Date: Wed, 08 Jan 2020 15:17:11 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 14:17:18 -0000 Moin! On 8 Jan 2020, at 14:23, Ted Lemon wrote: > In order to address this problem, the operator of a host using this > mechanism would need to explicitly configure a trust relationship with > the operator. Why? Is changing DNS traffic from unencrypted to encrypted considered a bad idea? Requiring additional configuration on the end devices will lead to centralisation and thus reduce privacy. We have less OS/App vendors then we have networks, which currently provide name resolution and I think we agree that the average user can’t make that decision, and even if they could we don’t have nowhere near the number of choices on DoH services that we have on networks providing regular DNS and might be willing to provide encrypted DNS via DoH or DoT for their users. All current deployment stratgeies for DoH are only considering globally available DoH servers, rather then per network servers that don’t serve other users. Network only DoH servers would be much better from privacy perspective as networks and end users often have a business relationship, and also could be scaled more easily making them more likely to appear. So long -Ralf —-- Ralf Weber From nobody Wed Jan 8 07:20:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D81120241 for ; Wed, 8 Jan 2020 07:20:31 -0800 (PST) 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 TSPxhZqB5Bxh for ; Wed, 8 Jan 2020 07:20:30 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097DC120846 for ; Wed, 8 Jan 2020 07:20:29 -0800 (PST) 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 2B31A6A257; Wed, 8 Jan 2020 16:20:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578496828; bh=PpsKya8xunpzZJbOgYkvkhS/G++qho6/DXHB6vp53sY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=X6MYe6ot1XHUeU5i1T+WpdbG7Z8eqFaHGshCQ71Eh+3MpfePP92ngG7IaN4PA+MVH OLenaxW46tgW/aeoUd7B2/h0lLdl77aMoWmddDp6Fu3OZu90rOiWpgsHRGmQXlLUxU QDuWYV2pxKuCegGs8nw2/hUXzbew+dLX4gwU+G8/GcrekzkXIrE583aGTwncPLYdxt 9wOoWQjsKRaGZ9sHA63ft6R3SataCIs9nVWfCjiOKUYLK5O+1ryf3lVeDszbICIISs v4SeTFu6SZ+jlpvqS8pB0vxxanF3JDSC0yXgtX8eBYtmWFj/sTBkbEVurg+Q1dUyoo PzOihgmk9AE0w== 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 1EBCA3C0310; Wed, 8 Jan 2020 16:20:28 +0100 (CET) Date: Wed, 8 Jan 2020 16:20:27 +0100 (CET) From: Vittorio Bertola To: Mirja Kuehlewind Cc: ADD Mailing list Message-ID: <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> In-Reply-To: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> 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.3-Rev3 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] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 15:20:38 -0000 > Il 08/01/2020 14:21 Mirja Kuehlewind ha scritto: > > The charter proposed by Tommy (see [1]) is exactly focusing on discovery and selection. What are you missing there? I think there partially is an issue of wording - the term "adaptive DNS", which you used to indicate the focus of the new work, to me indicates the architecture in Tommy's draft, which has the conceptual, non-technical problems I mentioned. Of course it is also a form of "discovery and selection", but in an opposite direction than the one that would address the problems that many of us have raised. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Jan 8 07:33:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEB612016E for ; Wed, 8 Jan 2020 07:33:03 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 yc5ePYd-T-2C for ; Wed, 8 Jan 2020 07:33:02 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 CFC0A12001A for ; Wed, 8 Jan 2020 07:33:01 -0800 (PST) Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipDKN-0003MX-P1; Wed, 08 Jan 2020 16:32:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind X-Priority: 3 In-Reply-To: <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> Date: Wed, 8 Jan 2020 16:32:59 +0100 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578497581;3d1708d0; X-HE-SMSGID: 1ipDKN-0003MX-P1 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 15:33:04 -0000 I think any discussion about selection policy (where e.g. one policy = could be to always prefer the resolver of your local operator if = encryption is offer), should take place in the new working group and not = at charter time. Maybe there is small change we can make to the charter = to ensure that people don=E2=80=99t think this option is excluded? Mirja > On 8. Jan 2020, at 16:20, Vittorio Bertola = wrote: >=20 >=20 >> Il 08/01/2020 14:21 Mirja Kuehlewind ha = scritto: >>=20 >> The charter proposed by Tommy (see [1]) is exactly focusing on = discovery and selection. What are you missing there? >=20 > I think there partially is an issue of wording - the term "adaptive = DNS", which you used to indicate the focus of the new work, to me = indicates the architecture in Tommy's draft, which has the conceptual, = non-technical problems I mentioned. Of course it is also a form of = "discovery and selection", but in an opposite direction than the one = that would address the problems that many of us have raised. >=20 > --=20 >=20 > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com=20 > Office @ Via Treviso 12, 10144 Torino, Italy >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add >=20 From nobody Wed Jan 8 08:35:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF80F120152 for ; Wed, 8 Jan 2020 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 e1vA3YN8xcme for ; Wed, 8 Jan 2020 08:35:30 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4EBD0120132 for ; Wed, 8 Jan 2020 08:35:30 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id f15so2896076lfl.13 for ; Wed, 08 Jan 2020 08:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MoI22Olqgs0XetbvRwVJmAZkgvNEwHQg/YAqx19z+m0=; b=qjCoxg5sNhr64vuLZm8beVfaEa0/BOh/+lb80ubZdjPDESPMYjKspFKnrJU7K80DlW xHkNMOKhTyYtclmGoNaDNF8AIEceRWVR+voI6/3Sp1uD21ogfyNO1/k/7u9ndIm1FPKp IO6WgPCUpwbK6ul8jAGPjS6i6yN8eVaYZ2wHeICNv5AL/I03aJSFzc0pgN1GSaveMda0 FRkEFc28tIa9wDe2AbY0aY8omZP4rke7XcgcDUVZtWXTnrJKiR85n40wNZHkcWttVNKB eIXa6d9++sp6R+zQMzTkNsdY+6CAvGBWpA1jvDY6acYD6nTZiYrSBS6proUcPj/gM2xl URqg== 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=MoI22Olqgs0XetbvRwVJmAZkgvNEwHQg/YAqx19z+m0=; b=Zq9pvrePKXUGeLuTxYL/h19NafivP3SMcBTFDM2BAkTEPqG1G3Oeoz0e+03oj5rxBi YHE6j3wM0TK10UwYwbGh5Sns9/LrOuApiTA1P/4l5r4rJ+Prm3R4DZ3jiiP7K3WnfyzY WZVQv1pqf8iIZjVo2g2YwHnF2ST+4Y6I6O+wjt20lB+Mi2p1N05WJgBxn6RYUrfpTan1 cXFEA61gCMtEYT1mJvPxywdZvnqD2uDHm4SzXPpeWjCVL7O1boh2ELCSUevf30NhkNOy 23+X9m6KpfflPUhkH202IfC33vYEO8tlGzWwEaPJAlixNLF49Kbf1lnkciCc/vmbHbN0 HPxA== X-Gm-Message-State: APjAAAXqS3nHMifTQqVuDyUd/ay+Q1NyoW91d8HVQvEqzkq8PCAhXJlM /6GSFwRGctmGYq7bts5qepEgJkbSfXbtbJgo6TWKN4VgxnI= X-Google-Smtp-Source: APXvYqy5I8SjYaSbdbOdYbo/3AJx4Mk3o0nmWhZHThsDgiJ/EFy+fpEwbjldSCee9lAHBVb2g6M8K8PR/bd6frB6bMg= X-Received: by 2002:a19:f006:: with SMTP id p6mr3298274lfc.94.1578501328525; Wed, 08 Jan 2020 08:35:28 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> In-Reply-To: <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> From: Eric Rescorla Date: Wed, 8 Jan 2020 08:34:51 -0800 Message-ID: To: Mirja Kuehlewind Cc: Vittorio Bertola , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f6f242059ba37aa7" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 16:35:33 -0000 --000000000000f6f242059ba37aa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I (and a number of others) have said, I believe we should explicitly keep such questions of policy out of scope. It seems quite clear we're not going to get anywhere near consensus on them, so it's just a recipe for a WG that doesn't do anything productive. I think it's fine to have a charter to develop mechanisms for discovery -Ekr On Wed, Jan 8, 2020 at 7:33 AM Mirja Kuehlewind wrote= : > I think any discussion about selection policy (where e.g. one policy coul= d > be to always prefer the resolver of your local operator if encryption is > offer), should take place in the new working group and not at charter tim= e. > Maybe there is small change we can make to the charter to ensure that > people don=E2=80=99t think this option is excluded? > > Mirja > > > > > On 8. Jan 2020, at 16:20, Vittorio Bertola 40open-xchange.com@dmarc.ietf.org> wrote: > > > > > >> Il 08/01/2020 14:21 Mirja Kuehlewind ha scritto: > >> > >> The charter proposed by Tommy (see [1]) is exactly focusing on > discovery and selection. What are you missing there? > > > > I think there partially is an issue of wording - the term "adaptive > DNS", which you used to indicate the focus of the new work, to me indicat= es > the architecture in Tommy's draft, which has the conceptual, non-technica= l > problems I mentioned. Of course it is also a form of "discovery and > selection", but in an opposite direction than the one that would address > the problems that many of us have raised. > > > > -- > > > > 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 > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000f6f242059ba37aa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I (and a number of others) have said, I believe we= should explicitly keep such questions of policy out of scope. It seems qui= te clear we're not going to get anywhere near consensus on them, so it&= #39;s just a recipe for a WG that doesn't do anything productive. I thi= nk it's fine to have a charter to develop mechanisms for discovery
<= /div>

-Ekr


On Wed, Jan 8, 2020 at 7:= 33 AM Mirja Kuehlewind <ietf@kueh= lewind.net> wrote:
I think any discussion about selection policy (where e.g. one po= licy could be to always prefer the resolver of your local operator if encry= ption is offer), should take place in the new working group and not at char= ter time. Maybe there is small change we can make to the charter to ensure = that people don=E2=80=99t think this option is excluded?

Mirja



> On 8. Jan 2020, at 16:20, Vittorio Bertola <vittorio.bertola=3D40open-x= change.com@dmarc.ietf.org> wrote:
>
>
>> Il 08/01/2020 14:21 Mirja Kuehlewind <ietf@kuehlewind.net> ha scritto:
>>
>> The charter proposed by Tommy (see [1]) is exactly focusing on dis= covery and selection. What are you missing there?
>
> I think there partially is an issue of wording - the term "adapti= ve DNS", which you used to indicate the focus of the new work, to me i= ndicates the architecture in Tommy's draft, which has the conceptual, n= on-technical problems I mentioned. Of course it is also a form of "dis= covery and selection", but in an opposite direction than the one that = would address the problems that many of us have raised.
>
> --
>
> 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
>

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000f6f242059ba37aa7-- From nobody Wed Jan 8 09:03:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADAA1200F3 for ; Wed, 8 Jan 2020 09:03:24 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocF1E8jkgm0n for ; Wed, 8 Jan 2020 09:03:22 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 DDCBA12020A for ; Wed, 8 Jan 2020 09:03:21 -0800 (PST) Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipEjl-0006Gv-SH; Wed, 08 Jan 2020 18:03:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 8 Jan 2020 18:03:17 +0100 Cc: ADD Mailing list , Vittorio Bertola Content-Transfer-Encoding: quoted-printable Message-Id: <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578503001;3f2b8614; X-HE-SMSGID: 1ipEjl-0006Gv-SH Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 17:03:25 -0000 Hi Ekr, I see your concern about having an endless discussion about possible = policies. And I agree that the proposed group might not be the right = place for it. However, when we say policy that is a quite generic term. = As I already said, I think questions about which policy to use where = should be discussed in an OPS group and we already have an OPS group for = DNS. However, I also don=E2=80=99t think we can design discovery = mechanism without having certain policies in mind. So having a certain = set of policies that can be supported by the section mechanism that uses = the discovery mechanism has to be defined. Adaptive DNS, as proposed = currently, implicitly defines a default policy that would, if not = configured otherwise, prefers the designated resolver. However, this is = not put as a requirement in the charter and something that can be = further discussed in the working group. I also support to keep the part of communicating local policy as = currently in the proposed charter. I think this is especially important = for enterprise or otherwise more closely managed/trusted network. I=E2=80=99= d be okay to limit the charter to that use case initially, as it might = be good to focus discussion, but I think it is important to have that = use case in mind when design discovery mechanisms. Mirja > On 8. Jan 2020, at 17:34, Eric Rescorla wrote: >=20 > As I (and a number of others) have said, I believe we should = explicitly keep such questions of policy out of scope. It seems quite = clear we're not going to get anywhere near consensus on them, so it's = just a recipe for a WG that doesn't do anything productive. I think it's = fine to have a charter to develop mechanisms for discovery >=20 > -Ekr >=20 >=20 > On Wed, Jan 8, 2020 at 7:33 AM Mirja Kuehlewind = wrote: > I think any discussion about selection policy (where e.g. one policy = could be to always prefer the resolver of your local operator if = encryption is offer), should take place in the new working group and not = at charter time. Maybe there is small change we can make to the charter = to ensure that people don=E2=80=99t think this option is excluded? >=20 > Mirja >=20 >=20 >=20 > > On 8. Jan 2020, at 16:20, Vittorio Bertola = wrote: > >=20 > >=20 > >> Il 08/01/2020 14:21 Mirja Kuehlewind ha = scritto: > >>=20 > >> The charter proposed by Tommy (see [1]) is exactly focusing on = discovery and selection. What are you missing there? > >=20 > > I think there partially is an issue of wording - the term "adaptive = DNS", which you used to indicate the focus of the new work, to me = indicates the architecture in Tommy's draft, which has the conceptual, = non-technical problems I mentioned. Of course it is also a form of = "discovery and selection", but in an opposite direction than the one = that would address the problems that many of us have raised. > >=20 > > --=20 > >=20 > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > > vittorio.bertola@open-xchange.com=20 > > Office @ Via Treviso 12, 10144 Torino, Italy > >=20 > > --=20 > > Add mailing list > > Add@ietf.org > > https://www.ietf.org/mailman/listinfo/add > >=20 >=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 From nobody Wed Jan 8 09:55:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625112011B for ; Wed, 8 Jan 2020 09:55:01 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 BZS7g-KZpQ2B for ; Wed, 8 Jan 2020 09:54:58 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 F26F01200B8 for ; Wed, 8 Jan 2020 09:54:57 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id x184so2001579pfb.3 for ; Wed, 08 Jan 2020 09:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MfWI7P7voaCaVcfcsKrR6QtoVCrmbIEzzRq9/CWEEbw=; b=a5iAoZeBv6VFsMnmRO/M97PdO7Pfyq3OmGcZqNhlV7TTJrYtw+J5jcb5zeuqODuvQY kxgD8bm+37MHT/IIIbJxqKyt7WdHizwTMwxi8vA+vnRDKV9ssGSz+fM+UcCp6WySxOD5 JhgPK7ysMUcWUUpZnNkqQ5QaSYkKwMvOpROraxEGu5qd3MjW0ww3wMEZtUaXiRPX8gRE ZuGUZcYs+XahbKzbGf11ukf+I3h5XjzEzstKO/2dX1wzjtFfengvzxk8NYvILVsO4oQF SvL/5g2Fp9Kk3YeoDsGTQb7dTFSdjOqxrexnWl7hciXZXZ+JM0gQjC/O1Fbj0el7HzBa 6qPQ== 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=MfWI7P7voaCaVcfcsKrR6QtoVCrmbIEzzRq9/CWEEbw=; b=hrgbCZo055Ha3ySshBaulnVhfHTIyDKSpd5oGmlsmEzGL5WOagMCJFl8nGGtv9RzXp c4U5TF/RipqJ4QoGbnMqjZZqqnRTVs84GjJRpcAS9Y5gnG3meedMh0j53B9UzcoS37Ip efVUjGTUTQmLyKNZEY8qZIWnPSLZ7bB4Q3gLAvwyNvqpCARvNqqYt8ORnOoJtjg3tSN0 h7mXUWCbm9fdJF/K2WVlNXjbeh++DyzYVm+Vx2AOwLzdmdTEJIzy7fIXOAfNWmz0G0Mf 9kCJJsmgUB4cdHSNyr5a7v/bogNzy0MjlsJQeclObfCNslv0eo+naGh2Sb0m6KZbePdR avxA== X-Gm-Message-State: APjAAAVDFHjRx9s+az7EDiXb4x6QtW0GFIa7Al7NZNGiZ9MnOH4oge+l TbrnD+wULjVz9g5wbg3CYmRjgQ== X-Google-Smtp-Source: APXvYqyeX4C/tq78XEoD+qeWjAA2gcPPM8UZbOIoGfppNHpkXAu58ob8EsMS6+fZKnQl/WZ59Stb2A== X-Received: by 2002:aa7:9474:: with SMTP id t20mr6178406pfq.241.1578506097228; Wed, 08 Jan 2020 09:54:57 -0800 (PST) Received: from [172.16.232.32] ([144.178.28.0]) by smtp.gmail.com with ESMTPSA id j9sm4354507pff.6.2020.01.08.09.54.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 09:54:56 -0800 (PST) From: Ted Lemon Message-Id: <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_728F2DA9-4279-46D1-B656-E0D209D750C0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 8 Jan 2020 09:54:55 -0800 In-Reply-To: <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> Cc: Eric Rescorla , ADD Mailing list , Vittorio Bertola To: Mirja Kuehlewind References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 17:55:02 -0000 --Apple-Mail=_728F2DA9-4279-46D1-B656-E0D209D750C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 8, 2020, at 9:03 AM, Mirja Kuehlewind = wrote: > I also support to keep the part of communicating local policy as = currently in the proposed charter. This statement contains an embedded assumption that you may not be aware = of: that it makes sense for the network to communicate resolver = configuration policy to clients. I don=E2=80=99t think this is an = assumption that we generally agree on. The usual counterexample given is that I definitely don=E2=80=99t want = Starbucks to tell me what resolver configuration policy I must use. We = tend to go around and around on this, and it=E2=80=99s not something we = can ever agree on. I think this is a big part of ekr=E2=80=99s reason = for saying we shouldn=E2=80=99t put this in the charter, and I agree = with that. It could make sense to make a list of possible policies that could be = configured on a host, and talk about how to address those policies. One = of those policies could be =E2=80=9Ctrust what the network says.=E2=80=9D = This would make sense on infrastructure devices. However, even in = this case it would make sense to have a way to actually establish trust, = and not just assume trust. E.g., for Thread networks, there is a = commissioning process. If we wanted a Thread device to use DoH (not = clear we want that, but just as an example), then the trust = establishment process could be done automatically when the device is = commissioned onto the network. So practically speaking, I don=E2=80=99t actually see any reason why = we=E2=80=99d ever want to encourage a protocol that would allow the = network to replace a trusted resolver configuration with an untrusted = resolver configuration. And the problem seems to be that some people = participating in this discussion, whether out of ignorance or = conviction, are in fact arguing that we should put that in the charter. --Apple-Mail=_728F2DA9-4279-46D1-B656-E0D209D750C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 8, 2020, at 9:03 AM, Mirja Kuehlewind <ietf@kuehlewind.net>= wrote:
I also = support to keep the part of communicating local policy as currently in = the proposed charter.

This statement contains an embedded assumption that you may = not be aware of: that it makes sense for the network to communicate = resolver configuration policy to clients.   I don=E2=80=99t think = this is an assumption that we generally agree on.
The usual counterexample given is that = I definitely don=E2=80=99t want Starbucks to tell me what resolver = configuration policy I must use.   We tend to go around and around = on this, and it=E2=80=99s not something we can ever agree on.  I = think this is a big part of ekr=E2=80=99s reason for saying we = shouldn=E2=80=99t put this in the charter, and I agree with = that.

It could = make sense to make a list of possible policies that could be configured = on a host, and talk about how to address those policies.  One of = those policies could be =E2=80=9Ctrust what the network says.=E2=80=9D =   This would make sense on infrastructure devices.   However, = even in this case it would make sense to have a way to actually = establish trust, and not just assume trust.   E.g., for Thread = networks, there is a commissioning process.   If we wanted a Thread = device to use DoH (not clear we want that, but just as an example), then = the trust establishment process could be done automatically when the = device is commissioned onto the network.

So practically speaking, I don=E2=80=99t = actually see any reason why we=E2=80=99d ever want to encourage a = protocol that would allow the network to replace a trusted resolver = configuration with an untrusted resolver configuration.   And the = problem seems to be that some people participating in this discussion, = whether out of ignorance or conviction, are in fact arguing that we = should put that in the charter.


= --Apple-Mail=_728F2DA9-4279-46D1-B656-E0D209D750C0-- From nobody Wed Jan 8 10:16:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F09120887 for ; Wed, 8 Jan 2020 10:16:31 -0800 (PST) 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 lQ6TeE4xbgGp for ; Wed, 8 Jan 2020 10:16:29 -0800 (PST) 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 A007C12086E for ; Wed, 8 Jan 2020 10:16:29 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id k24so4240996ioc.4 for ; Wed, 08 Jan 2020 10:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aaXFYR4llAx2728hwCqa6aBzq3p4ZtQgccbZnGOWRa4=; b=p/wotoy/JdvPJJ6iw6VEWFwjB1y/woUERfkX5dnzAbH2qcoOIR+5CvKmfG/dJucRxU leFHw5g4rbn9W1Bpw+yu4mxjLywgykddqfLYEwxmSzjzx/vRh9ZrmDX2pCo8Ta6n2y7C tQpQIihMQKf7YZ3rbasIbmMcghovwQvHu0jr+b9DDgJOauUTV1hufUApp1ggJKnCSRzx s+muPkp0L2ehfpVMM80Q1SlcVFUVU9e7hexiIrMMYJv5XEFTaRqND6kTsy+IxXjCDclq 9Cb6vsQ25EBIXwBDONdVdzrSfbI30O+sOyG9TjmM7OZUPDouimIYoztmzVJU9MAVx5QO bo4g== 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=aaXFYR4llAx2728hwCqa6aBzq3p4ZtQgccbZnGOWRa4=; b=omFpyv10ijR0ApCbynOJmP5bK1ZmJCe7/8Z8DB+LsCPd3tWJLmL1aycOOE8fCMoBA6 jtYyHwKtoDBONYhT47wNbhJaD1P+TPm70VapAzXbikqvIvBjlQvBjCZx6Jex5jH9q8NN 4DY70jpyikzoMWcOwvquoun0HXBtuyVXHDyZMYuHCqXsLzNfkdMPYuuXVO+2lb7Gd449 pfre8J0eWDK4RDNroR2bTMKsCmwXFaI0mjWEVQ1gYrtcckHLQhK9tTCu94/L9nXru2sP jZNEqVqPwZRBlTJeD8x4T4mASCY1NBYoGRQoMpqqjbcGfYwLVamy9kREcyVTfTSaQtsX iKgA== X-Gm-Message-State: APjAAAU4N+Y6oaZQ+hsAe9zEcBBtxwkP+xq8x7brMTJHFyDAUXi0Y7Zb stSWnJJJQu+OQvFJHlyKBC1v/9UFTZ8UGasn6esK9BbZpww= X-Google-Smtp-Source: APXvYqy38RwEmwmpW7PaGASBNLVkq03Q8Gxe96nOP/NjMC96ouqCSItd0xwGiGtbH8fburLF+Cgw5GzXtmJqt1W9kNo= X-Received: by 2002:a02:b893:: with SMTP id p19mr5103548jam.103.1578507388752; Wed, 08 Jan 2020 10:16:28 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> In-Reply-To: <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> From: Rob Sayre Date: Wed, 8 Jan 2020 10:16:16 -0800 Message-ID: To: Ted Lemon Cc: Mirja Kuehlewind , Eric Rescorla , ADD Mailing list , Vittorio Bertola Content-Type: multipart/alternative; boundary="0000000000002ea0b0059ba4e496" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 18:16:31 -0000 --0000000000002ea0b0059ba4e496 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 9:55 AM Ted Lemon wrote: > On Jan 8, 2020, at 9:03 AM, Mirja Kuehlewind wrote: > > I also support to keep the part of communicating local policy as currentl= y > in the proposed charter. > > > So practically speaking, I don=E2=80=99t actually see any reason why we= =E2=80=99d ever > want to encourage a protocol that would allow the network to replace a > trusted resolver configuration with an untrusted resolver configuration. > And the problem seems to be that some people participating in this > discussion, whether out of ignorance or conviction, are in fact arguing > that we should put that in the charter. > Adding to that: I seriously doubt proposals that change the resolution order in Adaptive DNS would be productive. When I read that draft, it seems like more of a description of what's going to happen (and is happening in an ad-hoc way), rather than a design decision a WG might productively debate. thanks, Rob --0000000000002ea0b0059ba4e496 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 8, 2020 at 9:55 AM Ted Le= mon <mellon@fugue.com> wrote:=
On Jan 8, 2020, at 9:03 AM, Mirja Kuehlewind <= ;ietf@kuehlewind.n= et> wrote:
I also support to keep the part of communicat= ing local policy as currently in the proposed charter.

So practically speaking, I don=E2=80=99t act= ually see any reason why we=E2=80=99d ever want to encourage a protocol tha= t would allow the network to replace a trusted resolver configuration with = an untrusted resolver configuration. =C2=A0 And the problem seems to be tha= t some people participating in this discussion, whether out of ignorance or= conviction, are in fact arguing that we should put that in the charter.

Adding to that: I seriously doubt= proposals that change the resolution order in Adaptive DNS would be produc= tive. When I read that draft, it seems like more of a description of what&#= 39;s going to happen (and is happening in an ad-hoc way), rather than a des= ign decision a WG might productively debate.

thank= s,
Rob
--0000000000002ea0b0059ba4e496-- From nobody Wed Jan 8 13:34:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD701201EA for ; Wed, 8 Jan 2020 13:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtL2hbJLx-M7 for ; Wed, 8 Jan 2020 13:34:27 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 55F7312012A for ; Wed, 8 Jan 2020 13:34:27 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 008LPsWZ031983; Wed, 8 Jan 2020 16:34:25 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2xdmndc1p6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2020 16:34:25 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 008LYNLa002781; Wed, 8 Jan 2020 16:34:24 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 008LYGER002559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Jan 2020 16:34:18 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id CF4A1400A0A7; Wed, 8 Jan 2020 21:34:16 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id B14EA4009E75; Wed, 8 Jan 2020 21:34:16 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.148]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Wed, 8 Jan 2020 16:34:16 -0500 From: "STARK, BARBARA H" To: "'Ted Lemon'" , "'Mirja Kuehlewind'" CC: "'Eric Rescorla'" , "'ADD Mailing list'" , "'Vittorio Bertola'" Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVt0kQma20/9Ym9keiujEJ3hlN+afbGwiAgAL7pICAAxeXAIAABAWAgAAhR4CAAAOAgIAAEUmAgAAH8oCAAA5tgP//21Uw Date: Wed, 8 Jan 2020 21:34:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> In-Reply-To: <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.100.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-08_06:2020-01-08, 2020-01-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 suspectscore=0 phishscore=0 mlxscore=0 clxscore=1011 spamscore=0 mlxlogscore=962 impostorscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001080168 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 21:34:29 -0000 RnJvbTogVGVkIExlbW9uDQoNCj4gIFNvIHByYWN0aWNhbGx5IHNwZWFraW5nLCBJIGRvbuKAmXQg YWN0dWFsbHkgc2VlIGFueSByZWFzb24gd2h5IHdl4oCZZCBldmVyIHdhbnQgdG8gZW5jb3VyYWdl IGENCj4gIHByb3RvY29sIHRoYXQgd291bGQgYWxsb3cgdGhlIG5ldHdvcmsgdG8gcmVwbGFjZSBh IHRydXN0ZWQgcmVzb2x2ZXIgY29uZmlndXJhdGlvbiB3aXRoIGFuIA0KPiAgdW50cnVzdGVkIHJl c29sdmVyIGNvbmZpZ3VyYXRpb24uIMKgIA0KDQpXaG8gZ2V0cyB0byBkZWZpbmUgInRydXN0ZWQg cmVzb2x2ZXIiPyANCg0KSSwgcGVyc29uYWxseSwgaGF2ZSBtYWRlIGEgY2hvaWNlIHRvIGFsbG93 IG15IElTUCB0byB1c2UgbXkgRE5TIHF1ZXJpZXMgdG8gY3JlYXRlIGEgcHJvZmlsZSBvZiBtZSBm b3IgbW9yZSB0YXJnZXRlZCBhZHMgKHRoaXMgZG9lc24ndCBpbmNyZWFzZSB0aGUgbnVtYmVyIG9m IGFkcyAtLSBpdCBqdXN0IG1ha2VzIHRoZW0gbW9yZSByZWxldmFudCB0byBtZSkuIEknbSBub3Qg YWxvbmUgaW4gdGhpcy4gVGhlcmUgYXJlIG1hbnkgcGVvcGxlIHdobyBwcmVmZXIgZm9yIHRoZSBh ZHMgdGhleSBzZWUgdG8gYmUgbW9yZSByZWxldmFudC4gVGhlcmUgYXJlIGFsc28gcGVvcGxlIHdo byBmaW5kIHRhcmdldGVkIGFkcyBjcmVlcHkuIE15IElTUCBwcm92aWRlcyBtZSB3aXRoIGEgd2Vi IHBhZ2Ugd2hlcmUgSSBjYW4gbWFrZSB0aGlzIGNob2ljZS4gTXkgSVNQIGFsc28gdGVsbHMgbWUg IlVubGVzcyB5b3UgZ2l2ZSB1cyBleHBsaWNpdCBwZXJtaXNzaW9uLCB3ZSBkb27igJl0IHNlbGwg ZGF0YSB0aGF0IGRpcmVjdGx5IGlkZW50aWZpZXMgeW91LiIgSSBoYXZlbid0IGdpdmVuIHN1Y2gg ZXhwbGljaXQgcGVybWlzc2lvbi4gVG8gbWUsIHRoZXJlJ3MgYSBodWdlIGRpZmZlcmVuY2UgYmV0 d2VlbiBzZWxsaW5nIG15IGRhdGEgYW5kIHNlbGxpbmcgYW4gYWQgYmFzZWQgb24gbXkgZGF0YS4g SG93IEkgZGVmaW5lIHByaXZhY3kgZm9yIG1lIGlzIG15IGRlY2lzaW9uLiBOb3QgYW55b25lIGVs c2Uncy4gDQoNCkknbSBhbHNvIHByZXR0eSBzdXJlIHRoZSBlbnRlcnByaXNlIHRydXN0cyB0aGVp ciBvd24gcmVzb2x2ZXIgZm9yIHVzZSBpbiB0aGVpciBuZXR3b3JrIG1vcmUgdGhhbiB0aGV5IHRy dXN0IGEgcXVhZC1uIHJlc29sdmVyLg0KDQpXaHksIGluZGVlZCwgYXJlIHdlIGVuY291cmFnaW5n IGEgcHJvdG9jb2wgdGhhdCBjYW4gYmUgdXNlZCBieSBhcHBsaWNhdGlvbnMgdG8gcmVwbGFjZSB0 aGUgcmVzb2x2ZXIgSSBhbmQgZW50ZXJwcmlzZSBuZXR3b3JrIG9wZXJhdG9ycyB0cnVzdCB3aXRo IG9uZSB0aGF0IHdlIGRvbid0Pw0KDQpIb3dldmVyLCBJIGRvIHRoaW5rIGl0IHdvdWxkIGJlIHVz ZWZ1bCB0byBzZWUgaWYgd2UgY2FuIGNvbWUgdXAgd2l0aCBhIHJlYXNvbmFibGUgd2F5IHRvIGNv bW11bmljYXRlIHJlc29sdmVyIHBvbGljeS4gRXZlbiBpZiBpdCdzIGp1c3QgYSB1cmwgd2hlcmUg eW91IGNhbiBpbmRpY2F0ZSB5b3VyIHByaXZhY3kgcHJlZmVyZW5jZXMgd2hlbiB1c2luZyB0aGF0 IHJlc29sdmVyLg0KQmFyYmFyYQ0K From nobody Wed Jan 8 14:40:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD4F12020A for ; Wed, 8 Jan 2020 14:40:45 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 AtYo1P_AJQ-C for ; Wed, 8 Jan 2020 14:40:41 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 5D55E1200C7 for ; Wed, 8 Jan 2020 14:40:41 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id q10so2338184pfs.6 for ; Wed, 08 Jan 2020 14:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7X5A/0fXPsrE+2w4Pb/+s2iee00Hi0mAZLZpZP5duPA=; b=p1JMsrOKCfRFcPxBZaWer/+VmZ0LGbh5+lbOt0b+VByrwJd9YMecldOlsSMa0EyjnD e7JK9vNb4WhJxV9JcKYjS6v+lBk8r4nXQ9Ui/kTvKOXFQ+/tcBN0hdRQy3Ju8h9z5RAB +wvlZ0hfr7RV/Zwz3ZKphufV1NVjV7C+MClsbybePpdcgoa/aXn7OIOgHcoE0hPRGMiV lAQjSmW9QTXxsh9/hqG/MTkiNQCazG7v1Jr8bcVGTfFDKt6uvmDfJE9xy/R1km53Lu92 4kWUrYPV/HkPhweDma+z+NRCjEc6/sdVo7nmZnpL9t7/ZujgmCASh1wdSfno+Hqggcjm 4MfA== 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=7X5A/0fXPsrE+2w4Pb/+s2iee00Hi0mAZLZpZP5duPA=; b=trTbXRd68ZRCMtb1t4Y4mvs2xy3kJ/D+FeYZmH7N8c6afru1H8N3W3A8hPZDL1BPDv 7+vvUvMIqDpFh0vd3nZng3UJnW+tv8fazwccQWw8pMAOUbJyrX6/Cyyt5Tk/zRyQtrpP SH+wibi5545lJHgfPkPjmfLZGjaHk3XUuL5EDmb0gJ3OBlynssaGLlVLzix0jM76v+91 sDrgMh0ER9P3nDXCSKjjyygd8LqYt72f9cIyOGVhGD8PcChmM/RfBQQqr9/59drxuESV AKGR/fOUXCtFFIZA44wA38Udb6e2+9fyEpCGv4O6andA8PCrBi2k/aXKhZaCWWXBVRkx kheA== X-Gm-Message-State: APjAAAXwtq2OsiJ27oSFvr+kLhjzvGBWifJLstga1rTdhgOFKOY+fCFw at7KoYUKAAAutpL/w64f1NMUxg== X-Google-Smtp-Source: APXvYqwZ8x3lKtrUT+3y70ZlNWOjCj7F/98fQwpikQqMJLAH9yBXXybwpJ/FhX25fm0hWthT+ImytQ== X-Received: by 2002:a65:484d:: with SMTP id i13mr7828681pgs.32.1578523240586; Wed, 08 Jan 2020 14:40:40 -0800 (PST) Received: from [172.16.232.32] ([144.178.28.0]) by smtp.gmail.com with ESMTPSA id w4sm222913pjt.23.2020.01.08.14.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 14:40:39 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EBD068C1-5A4F-44B1-A1E4-314A37C6C9A6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 8 Jan 2020 14:40:38 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Mirja Kuehlewind , Eric Rescorla , ADD Mailing list , Vittorio Bertola To: "STARK, BARBARA H" References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 22:40:46 -0000 --Apple-Mail=_EBD068C1-5A4F-44B1-A1E4-314A37C6C9A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 8, 2020, at 1:34 PM, STARK, BARBARA H wrote: > Who gets to define "trusted resolver=E2=80=9D? A trusted resolver is a resolver that you are able to securely identify, = and for which you have configured a trust relationship. You being the = end-user, if they are savvy, or the host vendor if the end-user is not = savvy, or, as I suggested two messages back, a relationship established = as a result of the commissioning process for an infrastructure device. > I, personally, have made a choice to allow my ISP to use my DNS = queries to create a profile of me for more targeted ads (this doesn't = increase the number of ads -- it just makes them more relevant to me). = I'm not alone in this. There are many people who prefer for the ads they = see to be more relevant. There are also people who find targeted ads = creepy. My ISP provides me with a web page where I can make this choice. = My ISP also tells me "Unless you give us explicit permission, we don=E2=80= =99t sell data that directly identifies you." I haven't given such = explicit permission. To me, there's a huge difference between selling my = data and selling an ad based on my data. How I define privacy for me is = my decision. Not anyone else's.=20 OK. Wouldn=E2=80=99t it be nice to be able to explicitly configure = this, rather than relying on a completely non-secure configuration = process to hopefully set it up the way you want? That is, if you think = you are trusting your ISP, but in fact your home router has been pwned = and is sending all your traffic to a third party, wouldn=E2=80=99t you = want to know that that was happening? Wouldn=E2=80=99t you want it to = fail? In order to do that, you have to be able to configure a = verifiable trust relationship. > I'm also pretty sure the enterprise trusts their own resolver for use = in their network more than they trust a quad-n resolver. Indeed. And enterprise IT departments have onboarding processes, during = which verifiable trust relationships can be explicitly established. > Why, indeed, are we encouraging a protocol that can be used by = applications to replace the resolver I and enterprise network operators = trust with one that we don=E2=80=99t? I don=E2=80=99t follow. What do you mean? Are you saying we should = get rid of DoH? > However, I do think it would be useful to see if we can come up with a = reasonable way to communicate resolver policy. Even if it's just a url = where you can indicate your privacy preferences when using that = resolver. If it=E2=80=99s not verifiable, then you configuring a choice doesn=E2=80=99= t have any verifiable effect, so what=E2=80=99s the point? If you = don=E2=80=99t care about the trustworthiness of your resolver, you can = just use DHCP. --Apple-Mail=_EBD068C1-5A4F-44B1-A1E4-314A37C6C9A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 8, 2020, at 1:34 PM, STARK, BARBARA H <bs7652@att.com> = wrote:
Who gets to = define "trusted resolver=E2=80=9D?

A trusted resolver is a resolver that you are able = to securely identify, and for which you have configured a trust = relationship.   You being the end-user, if they are savvy, or the = host vendor if the end-user is not savvy, or, as I suggested two = messages back, a relationship established as a result of the = commissioning process for an infrastructure device.

I, personally, have = made a choice to allow my ISP to use my DNS queries to create a profile = of me for more targeted ads (this doesn't increase the number of ads -- = it just makes them more relevant to me). I'm not alone in this. There = are many people who prefer for the ads they see to be more relevant. = There are also people who find targeted ads creepy. My ISP provides me = with a web page where I can make this choice. My ISP also tells me = "Unless you give us explicit permission, we don=E2=80=99t sell data that = directly identifies you." I haven't given such explicit permission. To = me, there's a huge difference between selling my data and selling an ad = based on my data. How I define privacy for me is my decision. Not anyone = else's. 

OK. =  Wouldn=E2=80=99t it be nice to be able to explicitly configure = this, rather than relying on a completely non-secure configuration = process to hopefully set it up the way you want?   That is, if you = think you are trusting your ISP, but in fact your home router has been = pwned and is sending all your traffic to a third party, wouldn=E2=80=99t = you want to know that that was happening?   Wouldn=E2=80=99t you = want it to fail?   In order to do that, you have to be able to = configure a verifiable trust relationship.

I'm also pretty sure = the enterprise trusts their own resolver for use in their network more = than they trust a quad-n resolver.

Indeed. =  And enterprise IT departments have onboarding processes, during = which verifiable trust relationships can be explicitly = established.

Why, indeed, are we = encouraging a protocol that can be used by applications to replace the = resolver I and enterprise network operators trust with one that we = don=E2=80=99t?

I don=E2=80=99t = follow.   What do you mean?   Are you saying we should get rid = of DoH?

However,= I do think it would be useful to see if we can come up with a = reasonable way to communicate resolver policy. Even if it's just a url = where you can indicate your privacy preferences when using that = resolver.

If it=E2=80=99s not = verifiable, then you configuring a choice doesn=E2=80=99t have any = verifiable effect, so what=E2=80=99s the point?  If you don=E2=80=99t= care about the trustworthiness of your resolver, you can just use = DHCP.

= --Apple-Mail=_EBD068C1-5A4F-44B1-A1E4-314A37C6C9A6-- From nobody Wed Jan 8 15:48:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1E120886 for ; Wed, 8 Jan 2020 15:47:59 -0800 (PST) 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 XVjSXcqDnxIb for ; Wed, 8 Jan 2020 15:47:53 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 86F1C120857 for ; Wed, 8 Jan 2020 15:47:53 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id 195so2392025pfw.11 for ; Wed, 08 Jan 2020 15:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=v2swKpOS/S8G15ghRAF4INsNO+UxWSctaSGZUU8ZS4s=; b=H+DWil+h5sBVnJibYTd2kf1NQulNFaBqNjG8co+GlXk5T5dgOSKsYwJXY9T3U+GAIG d1r993m26PDz26TFIHDn5ua5Met49uvoObSif7VltS71YvXCZEwm/XJvgkncKBMmoLuG A3WUunLO/y22fghWe2XyXpSuToZ0KAxpdG1XQmfgrPqBnQuZKfO+RZ5DePHjKq6JSOyQ WoCBRH+bzffdjdvptYpWppRhyqq1IlKKEdPo3TL+gXrFCek3S3Hv5eR01jbdLpc0+xx4 X6I+stT6MW/TtFKcIyO49AoU5MnrkOmQOdGsvMiWffTbs17/aHsv06PXj4H/eqHV178S p7cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=v2swKpOS/S8G15ghRAF4INsNO+UxWSctaSGZUU8ZS4s=; b=CHcgout0vullaP08GwTb0pqN2IZgFBWF1YsM4kndNEf0sZ4UYAVFcqRrZxqIapKGsp pFnjrLP5vfLJVzYFX+mwi/OxAERwQ3Q/9JziHkIFvhricZVcyh6BZwMe8M8cI1mSaFDC VUwHg/15vMDxH/GVtPC/TuyKYYkvfGH4153zQZyvoT8tkYaE1LRYI99mQWyzgVRyK0QH QeDVz8SB+K0SX1sNHWt5nCkFhm7o9364Wevc1/fGJQe4BgnTkFwOUtMLn49QxbIggVoE sXjEPZ63bdQosrZ2NovSqkodiLERCP2uZzx1WGGSKSO4ODEsgfLI96VfWKk8T0CO5K3R twmw== X-Gm-Message-State: APjAAAVqUapgR/cApgzfJBmhdlfX7ZAXj8zIultSF0AwCtk46OI3sQlN Wrd69S2XhZALbOCs0HBk4t5xieDCKAU= X-Google-Smtp-Source: APXvYqzVGo4RjMo3J/wrQ2i5Tr2pIMg0HVBVvf9JexkXcU+P/hBhR8P+Wu9QF8voGhOFd9GFK97ACQ== X-Received: by 2002:a63:5657:: with SMTP id g23mr7842190pgm.452.1578527272487; Wed, 08 Jan 2020 15:47:52 -0800 (PST) Received: from [192.168.1.233] (cpe-108-185-101-45.socal.res.rr.com. [108.185.101.45]) by smtp.gmail.com with ESMTPSA id x11sm4713272pfn.53.2020.01.08.15.47.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 15:47:51 -0800 (PST) From: "Glenn Deen" To: "ADD Mailing list" Date: Wed, 08 Jan 2020 15:47:50 -0800 X-Mailer: MailMate Trial (1.13.1r5671) Message-ID: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8D59781C-4CFC-406C-9364-F7291B8AC4D2_=" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 08 Jan 2020 23:48:03 -0000 --=_MailMate_8D59781C-4CFC-406C-9364-F7291B8AC4D2_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable I=E2=80=99ve been working on this note for the last 2 days, going back an= d = forth trying to layout a path forward for ADD/ABCD. I=E2=80=99m sure it i= s not = perfect, but you wait for perfection you=E2=80=99ll never move productive= ly = forward. Please try to be kind when responding. As it standards currently there are two ABCD charter proposals [1] = https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw = and [2] = https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w = which have the same top level goal: Discovery and Selection of = Resolvers by a DNS Client, but they differ in the specific description = of deliverables as well as what they prescribe as the starting point and = approach. For full disclosure I was a contributor to (1), but that = said I see common goals exist across both which gives me hope. The discussion seems to be stuck with people talking past one another, = and a lack of focus on how to move forward. My intention is to try to = break that pattern by first breaking down why this is even being = discussed and then proposing a path forward. Why we are discussing this =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94-=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94 The real world deployment of the changes driven by Encrypted DNS = technologies like DoH and DoT and other changes being proposed like = Adaptive DNS and Ubiquitous DNS are being the need for Discovery and = Selection of DNS Resolvers. So this is neither an academic exercise nor = engineers wanting to change things for the sake of change. The need for Discovery and Selection of Resolvers by a DNS Client has = been raised on this list, at microphones, and on other lists such as the = EDDI Encrypted DNS Deployment Initiative list and meetings. The input = has come from a broad set of contributors that come from a wide cross = section of the participants who care about DNS including major browser = makers, OS makers, network operators, DNS operators, and others from = enterprises, and dare I say even it, from users too. We=E2=80=99ve even had a number of drafts submitted to DNS OPs and DNS Pr= iv So while I acknowledge that there is not 100% agreement on the above, as = if there ever is in such things, there does seem to a tremendous amount = of interest in the need for Discovery and Selection, as well as a broad = and diverse set of contributors wanting to work on it, and we have = groups actually working on building and deploying solutions as well. The conclusion is that there is a community of interest, contributors, = and adopters here, and the work is going to be done somehow and = somewhere which leaves the question for the IETF being the outstanding = questions of what part of that work is to be done with the IETF, what = exactly is the scope of that work? Having caught up on the proposals, suggestions, and comments it seems = that perhaps the biggest barrier is in trying to create the optimized = charter of deliverables, scope, and with prescriptive and proscribed = approaches that satisfies the various diverse views while also trying to = proscribe in how the WG shall do it. Essentially the various drafts have = elements of trying preemptively manage the WG=E2=80=99s work before the W= G has = a change to meet and engage. Each of the proposals cites one or more = specific drafts as the basis for the work, and that in turn seems to be = causing a lot of the debate as that level of prescription to the WG sets = proponents of the other approaches off. Getting back to making progress =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 I=E2=80=99d suggest that perhaps the approach of being too proscriptive i= n the = charter is not going to succeed and instead of trying to create the = optimal charter that assuages the various wants, fears, and hopes that = people have put out on the list, that we alternatively it approach it a = simpler way. - a key part of which will involve trusting the IETF = process and ourselves to work together to consciously do the right = thing. Instead of trying to put just the right words into the charter have = upfront cover every possible aspect and contingency as if the charter = itself was code, we do the following: (1) Create a charter with a clear, yet simple goals. (2) Create simple clear boundaries. (3) Let the WG members do the work of bringing together the various = proposals and discuss and work through the use-cases, needs, and = technical issues. Do not be overly detailed or proscriptive in the = charter, and let it organically evolve as needed via the WG = participants and under the WG Chairs management and oversight of the = ADs. Part of the problems in the previous attempts has been trying to = skip past this hard work by being proscriptive in the charter. This has = resulted in non-productive back and forth on the list instead of focused = discussion on the specifics in drafts. (4) Trust in the IETF process and give the chance for the WG Chairs and = the ADs to work together to manage the WG activity and to keep it on = track. Give the chairs the mission and ability, under the ever watchful = and wise guiding hands of the ADs, to manage the WG toward the focused = goal delivering the Discovery and Selection functionality that DNS = Clients need in deployments. (5) Remove any boiler plate or unneeded assertions, comments, guidance, = as well as anything that it obvious. A great example of something = obvious is saying in the charter that the WG will coordinate with other = groups or security area, because quite obviously they will, for there = isn=E2=80=99t any other choice is the WG is actually going to produce = documents that have a hope of getting approval in the IESG. If we did that then this is how this 5 points could play out: 1. Clear, yet simple goal such as: The WG will work on the problems of Discovery and Selection of = Recursive Resolvers by DNS Clients. The goals of the group are to: (1) Produce mechanisms which will enable a DNS Client to discover = the recursive resolvers available to it in the network environment it is connected to, with = recognition that the network environment for a DNS Client can change overtime such as a device moving between = different networks environments such as a home, an office, and a public space such as a cafe, or = others as identified by the WG. (2) Produce a framework where the DNS Client can obtain the = information needed by the client to select the DNS resolvers it chooses to use. 2. Simple clear boundaries, such as: The WG will limit its work to the technical aspects of discovery = and the technical aspects of the selection framework for DNS/53, DoH, and DoT operational environments. The WG is not chartered to work on non-technical areas such as = policy, except the conveyance of whatever policy information in the selection framework to enable DNS Clients to = make their selection. The WG is not charted to work on security, or privacy problems = beyond those essential to Discovery or Selection. 3. Let the WG do the work This means the WG won=E2=80=99t be told via that charter what WG dra= fts = or architectures it must start from. The WG would open the floor to drafts for consideration that cover = both proposals for Discovery or Selection, As well a problem statement drafts and use-case drafts that would = present the functional needs and considerations that the Discovery mechanisms, and Selection framework would need = to satisfy. This will be drive the discussion hopefully to be technical and = about specifics and get away from the ADD list issues. 4. Trust in the IETF process Hopefully the ADs will appoint WG chairs that are willing to stay = above the fray and focus on managing the WG process. 5. Remove any boiler plate or unneeded assertions, comments, guidance, = as well as anything that it obvious. See the above proposal under point (1) Clear, yet simple goal. This is a technical working group that will be run with hands on = supervision. The charter isn=E2=80=99t a legal statue that we need to avoid legal loopholes in, it=E2=80=99s not going to = litigated, and the AD=E2=80=99s and IESG can always Choose to refine the mission or even close the WG if it goes off = the rails. We have a tried and proven process to manage this sort of work; Let=E2=80=99s use it and get to= = work. This all comes together in the shaved down WG charter proposal: The WG will work on the problems of Discovery and Selection of = Recursive Resolvers by DNS Clients. The goals of the group are to: (1) Produce mechanisms which will enable a DNS Client to discover = the recursive resolvers available to it in the network environment it is connected to, with = recognition that the network environment for a DNS Client can change overtime such as a device moving between = different networks environments such as a home, an office, and a public space such as a cafe, or = others as identified by the WG. (2) Produce a framework where the DNS Client can obtain the = information needed by the client to select the DNS resolvers it chooses to use. The WG will limit its work to the technical aspects of discovery = and the technical aspects of the selection framework for DNS/53, DoH, and DoT operational environments. The WG is not chartered to work on non-technical areas such as = policy, except the conveyance of whatever policy information in the selection framework to enable DNS Clients to = make their selection. The WG is not charted to work on security, or privacy problems = beyond those essential to Discovery or Selection. - that=E2=80=99s it folks =E2=80=94 And we call it DNS-DS (DNS Discovery and Selection) Are there interesting topics and aspects of DNS being left out of this? = Absolutely, and for those there is DPRIV and DNS-OPS etc. They remain = the places to discuss those other things as appropriate. This WG is = just about D&S. Time is ticking away and IETF107 in Vancouver is now only 10 weeks away. = We could spend 10 more weeks talking past one another, or we could = settle on what needs to be done, hopefully get the ADs/IESG to buy in, = and get down to work. -Glenn Deen [1] = https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw [2] = https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w --=_MailMate_8D59781C-4CFC-406C-9364-F7291B8AC4D2_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I=E2=80=99ve been working on this note for the last 2 day= s, going back and forth trying to layout a path forward for ADD/ABCD. I=E2= =80=99m sure it is not perfect, but you wait for perfection you=E2=80=99l= l never move productively forward. Please try to be kind when respondin= g.

As it standards currently there are two ABCD charter prop= osals [1] https://mailarchive.ietf.org/= arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw and [2] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za= 4G9ZbCo_w which have the same top level goal: Discovery and Selecti= on of Resolvers by a DNS Client, but they differ in the specific descript= ion of deliverables as well as what they prescribe as the starting point = and approach. For full disclosure I was a contributor to (1), but that = said I see common goals exist across both which gives me hope.

The discussion seems to be stuck with people talking past= one another, and a lack of focus on how to move forward. My intention i= s to try to break that pattern by first breaking down why this is even be= ing discussed and then proposing a path forward.

Why we are discussing this
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94-=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

The real world deployment of the changes driven by Encryp= ted DNS technologies like DoH and DoT and other changes being proposed li= ke Adaptive DNS and Ubiquitous DNS are being the need for Discovery and S= election of DNS Resolvers. So this is neither an academic exercise nor e= ngineers wanting to change things for the sake of change.

The need for Discovery and Selection of Resolvers by a DN= S Client has been raised on this list, at microphones, and on other lists= such as the EDDI Encrypted DNS Deployment Initiative list and meetings. = The input has come from a broad set of contributors that come from a w= ide cross section of the participants who care about DNS including major = browser makers, OS makers, network operators, DNS operators, and others = from enterprises, and dare I say even it, from users too.

We=E2=80=99ve even had a number of drafts submitted to DN= S OPs and DNS Priv

So while I acknowledge that there is not 100% agreement o= n the above, as if there ever is in such things, there does seem to a tre= mendous amount of interest in the need for Discovery and Selection, as we= ll as a broad and diverse set of contributors wanting to work on it, and = we have groups actually working on building and deploying solutions as we= ll.

The conclusion is that there is a community of interest, = contributors, and adopters here, and the work is going to be done somehow= and somewhere which leaves the question for the IETF being the outstandi= ng questions of what part of that work is to be done with the IETF, what = exactly is the scope of that work?

Having caught up on the proposals, suggestions, and comme= nts it seems that perhaps the biggest barrier is in trying to create the = optimized charter of deliverables, scope, and with prescriptive and prosc= ribed approaches that satisfies the various diverse views while also tryi= ng to proscribe in how the WG shall do it. Essentially the various drafts= have elements of trying preemptively manage the WG=E2=80=99s work before= the WG has a change to meet and engage. Each of the proposals cites one= or more specific drafts as the basis for the work, and that in turn seem= s to be causing a lot of the debate as that level of prescription to the = WG sets proponents of the other approaches off.

Getting back to making progress
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

I=E2=80=99d suggest that perhaps the approach of being to= o proscriptive in the charter is not going to succeed and instead of tryi= ng to create the optimal charter that assuages the various wants, fears, = and hopes that people have put out on the list, that we alternatively it = approach it a simpler way. - a key part of which will involve trusting th= e IETF process and ourselves to work together to consciously do the right= thing.

Instead of trying to put just the right words into the ch= arter have upfront cover every possible aspect and contingency as if the = charter itself was code, we do the following:

(1) Create a charter with a clear, yet simple goals.

(2) Create simple clear boundaries.

(3) Let the WG members do the work of bringing together t= he various proposals and discuss and work through the use-cases, needs, a= nd technical issues. Do not be overly detailed or proscriptive in the ch= arter, and let it organically evolve as needed via the WG participants a= nd under the WG Chairs management and oversight of the ADs. Part of the = problems in the previous attempts has been trying to skip past this hard = work by being proscriptive in the charter. This has resulted in non-prod= uctive back and forth on the list instead of focused discussion on the sp= ecifics in drafts.

(4) Trust in the IETF process and give the chance for the= WG Chairs and the ADs to work together to manage the WG activity and to = keep it on track. Give the chairs the mission and ability, under the ever= watchful and wise guiding hands of the ADs, to manage the WG toward the = focused goal delivering the Discovery and Selection functionality that DN= S Clients need in deployments.

(5) Remove any boiler plate or unneeded assertions, comme= nts, guidance, as well as anything that it obvious. A great example of = something obvious is saying in the charter that the WG will coordinate wi= th other groups or security area, because quite obviously they will, for = there isn=E2=80=99t any other choice is the WG is actually going to produ= ce documents that have a hope of getting approval in the IESG.

If we did that then this is how this 5 points could play = out:

  1. Clear, yet simple goal such as:

    The WG will work on the problems of Discovery and Selecti= on of Recursive Resolvers by DNS Clients.

    The goals of the group are to:

    (1) Produce mechanisms which will enable a DNS Client to = discover the recursive resolvers available to
    it in the network environment it is connected to, with recognition tha= t the network environment for
    a DNS Client can change overtime such as a device moving between diffe= rent networks environments
    such as a home, an office, and a public space such as a cafe, or other= s as identified by the WG.

    (2) Produce a framework where the DNS Client can obtain t= he information needed by the client to select
    the DNS resolvers it chooses to use.

  2. Simple clear boundaries, such as:

    The WG will limit its work to the technical aspects of di= scovery and the technical aspects of the selection framework
    for DNS/53, DoH, and DoT operational environments.

    The WG is not chartered to work on non-technical areas su= ch as policy, except the conveyance of whatever policy
    information in the selection framework to enable DNS Clients to make thei= r selection.

    The WG is not charted to work on security, or privacy pro= blems beyond those essential to Discovery or Selection.

  3. Let the WG do the work

    This means the WG won=E2=80=99t be told via that charter = what WG drafts or architectures it must start from.

    The WG would open the floor to drafts for consideration t= hat cover both proposals for Discovery or Selection,
    As well a problem statement drafts and use-case drafts that would present= the functional needs and considerations
    that the Discovery mechanisms, and Selection framework would need to sati= sfy.

    This will be drive the discussion hopefully to be technic= al and about specifics and get away from the ADD list issues.

  4. Trust in the IETF process

    Hopefully the ADs will appoint WG chairs that are willing= to stay above the fray and focus on managing the WG process.

  5. Remove any boiler plate or unneeded asser= tions, comments, guidance, as well as anything that it obvious.

    See the above proposal under point (1) Clear, yet simple = goal.

    This is a technical working group that will be run with h= ands on supervision. The charter isn=E2=80=99t a legal statue
    that we need to avoid legal loopholes in, it=E2=80=99s not going to litig= ated, and the AD=E2=80=99s and IESG can always
    Choose to refine the mission or even close the WG if it goes off the rail= s. We have a tried and proven
    process to manage this sort of work; Let=E2=80=99s use it and get to work= =2E

This all comes together in the shaved down WG charter pro= posal:

The WG will work on the problems of Discovery and Selecti= on of Recursive Resolvers by DNS Clients.

The goals of the group are to:

(1) Produce mechanisms which will enable a DNS Client to = discover the recursive resolvers available to
it in the network environment it is connected to, with recognition= that the network environment for
a DNS Client can change overtime such as a device moving between d= ifferent networks environments
such as a home, an office, and a public space such as a cafe, or o= thers as identified by the WG.

(2) Produce a framework where the DNS Client can obtain t= he information needed by the client to select
the DNS resolvers it chooses to use.

The WG will limit=
 its work to the technical aspects of discovery and the technical aspects=
 of the selection framework
for DNS/53, DoH, and DoT operational environments.

The WG is not chartered to work on non-technical areas such as policy, ex=
cept the conveyance of whatever policy
information in the selection framework to enable DNS Clients to make thei=
r selection.

The WG is not charted to work on security, or privacy problems beyond tho=
se essential to Discovery or Selection.
  • that=E2=80=99s it folks =E2=80=94

And we call it DNS-DS (DNS Discovery and Selection)

Are there interesting topics and aspects of DNS being lef= t out of this? Absolutely, and for those there is DPRIV and DNS-OPS etc.= They remain the places to discuss those other things as appropriate. Th= is WG is just about D&S.

Time is ticking away and IETF107 in Vancouver is now only= 10 weeks away. We could spend 10 more weeks talking past one another, = or we could settle on what needs to be done, hopefully get the ADs/IESG t= o buy in, and get down to work.

-Glenn Deen

[1] https://mailarchive.= ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw
[2] https://mailarchive.ietf.org/arch/ms= g/add/XudG5id0wwdRndR5za4G9ZbCo_w

--=_MailMate_8D59781C-4CFC-406C-9364-F7291B8AC4D2_=-- From nobody Wed Jan 8 16:07:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDAF120142 for ; Wed, 8 Jan 2020 16:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 ABqCd_z-rBCa for ; Wed, 8 Jan 2020 16:07:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63541200A3 for ; Wed, 8 Jan 2020 16:07:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93C18BE2F; Thu, 9 Jan 2020 00:07:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-NUrYsv9cGf; Thu, 9 Jan 2020 00:07:05 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D3AE9BE20; Thu, 9 Jan 2020 00:07:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578528425; bh=FXqHfFF6L86TTtIxwgKjl/A3Vfv+fcvWgy7TNzGrbqc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=A2YIhilDAx+C/73nBT+7G4SwD29IwKnLxTZLwWb8RGwfKr3KbbNfgHQHlJl5bhv8N w2+BBp7CK6MsWHvX6MBTqE5qfKCH1FkuwnGDiXXtC8+diTGaAUl3A+3d5Um81tbKN8 578AHFwFqt7W2FVcWU8bcUjwI89xujecF/wsSL0c= To: Glenn Deen , ADD Mailing list References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> From: Stephen Farrell 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: <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> Date: Thu, 9 Jan 2020 00:07:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PwycE7tonTzqVxogvxqGRnjDWHYWE35of" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 00:07:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PwycE7tonTzqVxogvxqGRnjDWHYWE35of Content-Type: multipart/mixed; boundary="jugOKNsN4qWWwrMreVpZRJNRieAuag34Y"; protected-headers="v1" From: Stephen Farrell To: Glenn Deen , ADD Mailing list Message-ID: <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> Subject: Re: [Add] A proposed charter for ABCD References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> In-Reply-To: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> --jugOKNsN4qWWwrMreVpZRJNRieAuag34Y Content-Type: multipart/mixed; boundary="------------2DEE7619F4D6E097E9A94B1E" Content-Language: en-US This is a multi-part message in MIME format. --------------2DEE7619F4D6E097E9A94B1E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Glenn, Good try. Thanks. On 08/01/2020 23:47, Glenn Deen wrote: >=20 > The WG will work on the problems of Discovery and Selection of=20 > Recursive Resolvers by DNS Clients. >=20 > The goals of the group are to: >=20 > (1) Produce mechanisms which will enable a DNS Client to discover the > recursive resolvers available to it in the network environment it is > connected to, with recognition that the network environment for a DNS > Client can change overtime such as a device moving between different > networks environments such as a home, an office, and a public space > such as a cafe, or others as identified by the WG. I'm not 100% sure, but I strongly suspect that the above could turn into another set of ratholes if it's not clear from the charter whether or not insecure or opportunistic methods for discovery are ruled in or out. Yet, trying to determine that now is also likely a rathole;-( Could there be a way out via something like "Discovery mechanisms that could disimprove security or privacy in many existing networks are not in-scope. Mechanisms that 'do no worse' may (or may not) be acceptable subject to normal IETF rough consensus, (and it will be rough;-), processes"? Other than that, I'd be ok with such a charter and with other stuff being processes in dnsop or dprive as may make sense. S. >=20 > (2) Produce a framework where the DNS Client can obtain the=20 > information needed by the client to select the DNS resolvers it > chooses to use. >=20 >=20 > The WG will limit its work to the technical aspects of discovery and > the technical aspects of the selection framework for DNS/53, DoH, and > DoT operational environments. >=20 > The WG is not chartered to work on non-technical areas such as=20 > policy, except the conveyance of whatever policy information in the > selection framework to enable DNS Clients to make their selection. >=20 > The WG is not charted to work on security, or privacy problems beyond > those essential to Discovery or Selection. --------------2DEE7619F4D6E097E9A94B1E 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----- --------------2DEE7619F4D6E097E9A94B1E-- --jugOKNsN4qWWwrMreVpZRJNRieAuag34Y-- --PwycE7tonTzqVxogvxqGRnjDWHYWE35of Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4WbqcACgkQWrL68XsX K+rv+hAAgKcvuShIlN1VX9Ty+a1TkW5qz19WL8ci/1yAY2FwkBj2mDinPVQidads awDjd4/jrkemKlVX3cQ/+jem3MKLcZVLI320e4N8gkEFC5pObr9Fk3NOa4MJ7O0i aTBngjL3m3pbjHKG8BmH4pubadtvUcQ6bzPlEVzXXmSWZeVuIGbXhzYEVATJXn2c suHYPLRx94nSkVCNHmKcf4MH/ZLf/ovECOVj670Bpi49PQlyO76fdM6epD8ZdM4/ uhO87H+SMNTYtHmdBNL+ahUzjsWTZrWl2d3KNR8X1lA+F9qB+AMzjG89P4u34B5b M5AxqZVcrVoc8L2DfaA5ogH2jtdH0UKaeUHPocGXmWEOXXX2zNH9hlsgbAbh1nRv 4jEQzmDwwPfOGg3mHseBqlljzk7tZ5dlq0XnFg5GYdgEYMd0v28nAIKHSMzLDHUX HF6UBE2pucGKuAYy3NjWlte7cGiL43ff77LcbpVaX6qk02A//tYuD1X4l57V3C+Z fRgX5VMSjRGbyuoqmlQQBpPQJen5ltIQBKsGdf7KYkhhQIuqrEJ9nP/HGIUAdEwJ WecZccrCxRYdIBnC54qK5jA/jRpQCmGflbd2O5jvArH1HhPlFboiz7skYODckb5+ iehxDZg8hh1NGqSHTrETcOZIQeiTy5tF6CRPvOl47qh74mfZ5oM= =1bud -----END PGP SIGNATURE----- --PwycE7tonTzqVxogvxqGRnjDWHYWE35of-- From nobody Wed Jan 8 18:13:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F162F120020 for ; Wed, 8 Jan 2020 18:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 VWfQV1sqtAHt for ; Wed, 8 Jan 2020 18:13:01 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 8F818120142 for ; Wed, 8 Jan 2020 18:13:01 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id c7so1935168uaf.5 for ; Wed, 08 Jan 2020 18:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLwf7u1q3mmP7FUGkOmR9Dx/tns1MI9LQ6qAbg/+JCE=; b=NlJkKXboPmJy4oMHUI37HqxmBQ8LRXKmaarsjlL16/iaVdJ+JCHS25qz7whUhlpEJ4 fN5OHqwNgKHlk5/gVup5iCNMHUDdceHETpm5CPOApr5XvTZznwBIlK8hq0AjkJVqZHg0 ZgcriHvwfqIPrz3LBzkrZKCUBGlHbjInq7A3LdiEnw0i1NNO2UCuRDj63LrctV8uJW1g dXBqCWJoLkqG6wU+7LaJ5EmmiksnQFc5UxuGVmEIRTxlp83DcN5FyZimk9/xnEp3R3C8 ewf7umSEVktJ8aMiLkel1CBgOEb0eY9fDBWqIhwzy2EAKYPPsF9mA03qjbUE1TLF4LJY XFmw== 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=SLwf7u1q3mmP7FUGkOmR9Dx/tns1MI9LQ6qAbg/+JCE=; b=mgoAwGel5GJOMdR33Zgk/4XZ2m8/oaj7dLRKhjuY+GlqscincXit7bmre9li9Equ3F MNmarov0N61Jj+Y8Zz8vwVhwjFaZ35P3PceLXJ5drMOaDY5DbIROFYfpWYe8t1Ql8H6O ipcQeBksE++6bI5gw0KDzAGREX8sqcLMuhBKVRiOOP0/87xHW+dOUY5erElEDQhpiqvc HXZul1IgKroOAVEeN0p/CNF2/YCBQL3Wj3trL34V48aKa4S0cBftHLL22oLUqm7X9T2c HlxaRE9zi9a2VmLv9xnIzfN0QH3KJDhYWbPLG0qEvv01zBakV9hF34LknTYQRQzkzLMa ayHQ== X-Gm-Message-State: APjAAAVSJayS7y5zTYESIdshGRWZW7Jhs4MUAU+S8scnu6QI/kGCvS5x mPwtX2QjTVC4Mp1ZzKP+Ocb3KW9x5wyRTrpvQbI= X-Google-Smtp-Source: APXvYqyq+1sdxBJVSPUgac9ogy6s/AJXBzH8dDU2KXSmGP24ILVeu54IRqIJAzk+SIS22L1yiOahT+tIMnq/0/azCio= X-Received: by 2002:ab0:2505:: with SMTP id j5mr5250317uan.87.1578535980504; Wed, 08 Jan 2020 18:13:00 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: From: Brian Dickson Date: Wed, 8 Jan 2020 18:12:48 -0800 Message-ID: To: Ted Lemon Cc: "STARK, BARBARA H" , Eric Rescorla , ADD Mailing list , Mirja Kuehlewind , Vittorio Bertola Content-Type: multipart/alternative; boundary="000000000000621991059bab8c1e" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 02:13:09 -0000 --000000000000621991059bab8c1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 2:40 PM Ted Lemon wrote: > On Jan 8, 2020, at 1:34 PM, STARK, BARBARA H wrote: > > Who gets to define "trusted resolver=E2=80=9D? > > > A trusted resolver is a resolver that you are able to securely identify, > and for which you have configured a trust relationship. You being the > end-user, if they are savvy, or the host vendor if the end-user is not > savvy, or, as I suggested two messages back, a relationship established a= s > a result of the commissioning process for an infrastructure device. > > I, personally, have made a choice to allow my ISP to use my DNS queries t= o > create a profile of me for more targeted ads (this doesn't increase the > number of ads -- it just makes them more relevant to me). I'm not alone i= n > this. There are many people who prefer for the ads they see to be more > relevant. There are also people who find targeted ads creepy. My ISP > provides me with a web page where I can make this choice. My ISP also tel= ls > me "Unless you give us explicit permission, we don=E2=80=99t sell data th= at > directly identifies you." I haven't given such explicit permission. To me= , > there's a huge difference between selling my data and selling an ad based > on my data. How I define privacy for me is my decision. Not anyone else's= . > > > OK. Wouldn=E2=80=99t it be nice to be able to explicitly configure this,= rather > than relying on a completely non-secure configuration process to hopefull= y > set it up the way you want? That is, if you think you are trusting your > ISP, but in fact your home router has been pwned and is sending all your > traffic to a third party, wouldn=E2=80=99t you want to know that that was > happening? Wouldn=E2=80=99t you want it to fail? In order to do that,= you have > to be able to configure a verifiable trust relationship. > > There are a number of problems that I think can be addressed, that are worth pursuing relative to these questions. Not all of them can be completely solved, IMHO, but it may be possible to at least scope the problems or constrain the risk parameters at play. I think the starting point is some manner of user/machine/application "policy" (or policies), keeping things as simple as possible without ignoring real areas of contention. Concrete examples off the top of my head: - Having policies that can be managed (on managed devices) would be good. - Having policies that are in some manner tied to network identity or SSID, in terms of trust. Those are only as valuable as the ability to securely validate IDs. - Policies regarding preference of encrypted vs unencrypted DNS server (if more than one is available/known). - The ability for the client to assess the immediate environment, including passively or actively interacting with network elements (e.g. DHCP), and doing various kinds of discovery. There are some kinds of sanity check that would be good to apply, that would potentially be useful for alerting the user about what has been discovered. There are also ways of limiting the need to trust the local server, without having to change the default resolver. Specifically, if the local server is merely a forwarder, then discovering the upstream resolver would be valuable. Having the ability to bypass the forwarder means that any subsequent pwning of the router would be either inconsequential (since it isn't being used for DNS), or automatically detected (if it forwards all DNS traffic or all traffic, since it would break DoT/DoH). Another example where client discovery would be useful, regardless of the trust/security involved, is determining the latency to the resolver. Speed of light is pretty much a constant, so a lower bound on distance to the resolver can be easily established. Reporting to the client (user) that the resolver is not on the same continent, or not in the same metro area, or same time zone, is valuable regardless of the state of privacy/trust, particularly in the absence of configured resolvers. The trust relationship may be ephemeral, but may also be sufficient for many use cases. Reducing the risk to a level where the client is only at risk the first time the device is powered on, and only if the local network is pwned, is certainly a good baseline for better goals, and I think it's something that is achievable without too much work. Whether a given network should be trusted, is very much dependent on a combination of things: host profile (e.g. default provided by the manufacturer or OS vendor); user profile (e.g. managed by an employer); network profile (absent any other profiles); and application profile(s). To me, the question isn't whether a particular entity wants to supply a non-default value; it is whether any non-default policies exist, and the question of how multiple such policies can be suitably resolved. I think we can exclude the "multiple policies conflicting" aspect as out of scope, mostly, so long as we give appropriate consideration to handling a single non-default policy among all the potential scoped defaults or policies. Those policies might themselves include how to resolve such conflicts, in which case it might be sufficient to spec out the syntax and semantics of that, and expect all components of the system to honor whatever the policy is. If we assume generally multi-user devices, then what would seem to me to make the most sense is device-wide > user > app > network, where any higher-scope element can bypass the lower-scoped things to establish its own "rules". A device can configure itself to trust the network (and not be over-ridden by any user). A device without any such config, could be managed by the user (to manual configure something, or prefer the config by some particular app, or to have per-network selections used). If no user preferences (or overrides/logic) are used, then each app would be free to do its own thing. And lastly if no app is doing anything, default network behavior gets used (with lowest prevalence/priority), i.e. only if nothing else takes control of the policy. IMHO, the only time it is reasonable for an app to assert policy control, is in the absence of user or device policy assertion (possibly including vendor-standard policies which may differ by vendor.) Brian > I'm also pretty sure the enterprise trusts their own resolver for use in > their network more than they trust a quad-n resolver. > > > Indeed. And enterprise IT departments have onboarding processes, during > which verifiable trust relationships can be explicitly established. > > Why, indeed, are we encouraging a protocol that can be used by > applications to replace the resolver I and enterprise network operators > trust with one that we don=E2=80=99t? > > > I don=E2=80=99t follow. What do you mean? Are you saying we should ge= t rid of > DoH? > > However, I do think it would be useful to see if we can come up with a > reasonable way to communicate resolver policy. Even if it's just a url > where you can indicate your privacy preferences when using that resolver. > > > If it=E2=80=99s not verifiable, then you configuring a choice doesn=E2=80= =99t have any > verifiable effect, so what=E2=80=99s the point? If you don=E2=80=99t car= e about the > trustworthiness of your resolver, you can just use DHCP. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000621991059bab8c1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 8, 2020 at 2:40 PM Ted Le= mon <mellon@fugue.com> wrote:=
On Jan 8, 2020, at 1:34 PM, STARK, BARBARA H <= ;bs7652@att.com>= wrote:
Who gets to define "trusted resolver=E2=80=9D?

A trusted resolver is a resolver = that you are able to securely identify, and for which you have configured a= trust relationship. =C2=A0 You being the end-user, if they are savvy, or t= he host vendor if the end-user is not savvy, or, as I suggested two message= s back, a relationship established as a result of the commissioning process= for an infrastructure device.

I, personally, have made a= choice to allow my ISP to use my DNS queries to create a profile of me for= more targeted ads (this doesn't increase the number of ads -- it just = makes them more relevant to me). I'm not alone in this. There are many = people who prefer for the ads they see to be more relevant. There are also = people who find targeted ads creepy. My ISP provides me with a web page whe= re I can make this choice. My ISP also tells me "Unless you give us ex= plicit permission, we don=E2=80=99t sell data that directly identifies you.= " I haven't given such explicit permission. To me, there's a h= uge difference between selling my data and selling an ad based on my data. = How I define privacy for me is my decision. Not anyone else's.=C2=A0

OK.=C2=A0 Wouldn=E2=80=99t it be nice to be= able to explicitly configure this, rather than relying on a completely non= -secure configuration process to hopefully set it up the way you want? =C2= =A0 That is, if you think you are trusting your ISP, but in fact your home = router has been pwned and is sending all your traffic to a third party, wou= ldn=E2=80=99t you want to know that that was happening? =C2=A0 Wouldn=E2=80= =99t you want it to fail? =C2=A0 In order to do that, you have to be able t= o configure a verifiable trust relationship.


There are a number of problems that I th= ink can be addressed, that are worth pursuing relative to these questions.<= /div>
Not all of them can be completely solved, IMHO, but it may be pos= sible to at least scope the problems or constrain the risk parameters at pl= ay.

I think the starting point is some manner of u= ser/machine/application "policy" (or policies), keeping things as= simple as possible without ignoring real areas of contention.
Co= ncrete examples off the top of my head:
  • Having policies t= hat can be managed (on managed devices) would be good.=C2=A0
  • Having= policies that are in some manner tied to network identity or SSID, in term= s of trust. Those are only as valuable as the ability to securely validate = IDs.
  • Policies regarding preference of encrypted vs unencrypted DNS = server (if more than one is available/known).
  • The ability for the c= lient to assess the immediate environment, including passively or actively = interacting with network elements (e.g. DHCP), and doing various kinds of d= iscovery.
There are some kinds of sanity check that would be = good to apply, that would potentially be useful for alerting the user about= what has been discovered.
There are also ways of limiting = the need to trust the local server, without having to change the default re= solver. Specifically, if the local server is merely a forwarder, then disco= vering the upstream resolver would be valuable.
Having the abilit= y to bypass the forwarder means that any subsequent pwning of the router wo= uld be either inconsequential (since it isn't being used for DNS), or a= utomatically detected (if it forwards all DNS traffic or all traffic, since= it would break DoT/DoH).

Another example where cl= ient discovery would be useful, regardless of the trust/security involved, = is determining the latency to the resolver.=C2=A0
Speed of light = is pretty much a constant, so a lower bound on distance to the resolver can= be easily established.
Reporting to the client (user) that the r= esolver is not on the same continent, or not in the same metro area, or sam= e time zone, is valuable regardless of the state of privacy/trust, particul= arly in the absence of configured resolvers.

The t= rust relationship may be ephemeral, but may also be sufficient for many use= cases. Reducing the risk to a level where the client is only at risk the f= irst time the device is powered on, and only if the local network is pwned,= is certainly a good baseline for better goals, and I think it's someth= ing that is achievable without too much work.

Whet= her a given network should be trusted, is very much dependent on a combinat= ion of things: host profile (e.g. default provided by the manufacturer or O= S vendor); user profile (e.g. managed by an employer); network profile (abs= ent any other profiles); and application profile(s).

To me, the question isn't whether a particular entity wants to suppl= y a non-default value; it is whether any non-default policies exist, and th= e question of how multiple such policies can be suitably resolved.

I think we can exclude the "multiple policies conflic= ting" aspect as out of scope, mostly, so long as we give appropriate c= onsideration to handling a single non-default policy among all the potentia= l scoped defaults or policies.

Those policies migh= t themselves include how to resolve such conflicts, in which case it might = be sufficient to spec out the syntax and semantics of that, and expect all = components of the system to honor whatever the policy is.

If we assume generally multi-user devices, then what would seem to = me to make the most sense is device-wide > user > app > network, w= here any higher-scope element can bypass the lower-scoped things to establi= sh its own "rules".
A device can configure itself to tr= ust the network (and not be over-ridden by any user).
A device wi= thout any such config, could be managed by the user (to manual configure so= mething, or prefer the config by some particular app, or to have per-networ= k selections used).
If no user preferences (or overrides/logic) a= re used, then each app would be free to do its own thing.
And las= tly if no app is doing anything, default network behavior gets used (with l= owest prevalence/priority), i.e. only if nothing else takes control of the = policy.

IMHO, the only time it is reasonable for a= n app to assert policy control, is in the absence of user or device policy = assertion (possibly including vendor-standard policies which may differ by = vendor.)

Brian

=C2=A0
I'm also pretty sure the enterprise tr= usts their own resolver for use in their network more than they trust a qua= d-n resolver.
Indeed.=C2=A0 And enterprise IT departments have onboarding pr= ocesses, during which verifiable trust relationships can be explicitly esta= blished.

Why, indeed, are we encouraging a protocol that can be used b= y applications to replace the resolver I and enterprise network operators t= rust with one that we don=E2=80=99t?

I don=E2=80=99t follow. =C2=A0 What do = you mean? =C2=A0 Are you saying we should get rid of DoH?

However, I do think it would be useful to see if we can come up with a rea= sonable way to communicate resolver policy. Even if it's just a url whe= re you can indicate your privacy preferences when using that resolver.

If it= =E2=80=99s not verifiable, then you configuring a choice doesn=E2=80=99t ha= ve any verifiable effect, so what=E2=80=99s the point?=C2=A0 If you don=E2= =80=99t care about the trustworthiness of your resolver, you can just use D= HCP.

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000621991059bab8c1e-- From nobody Wed Jan 8 18:46:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC0A120086 for ; Wed, 8 Jan 2020 18:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 hcLkJshdNR-9 for ; Wed, 8 Jan 2020 18:46:52 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 8CB7012004F for ; Wed, 8 Jan 2020 18:46:52 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id k25so2467422pgt.7 for ; Wed, 08 Jan 2020 18:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dThJ/FYG9mi+kw5kkqtXTXspgSDbN8mx3j4nbRHWacY=; b=nDHdoKwcybUiPJX6Ufg39JMgDI06j3rRJ/32z4++1z4CUkcKDXKeVNl5qUDlmSU/dR 7muGLgq5h4fwOcBf90gSH0rvaSV3SeWYiXjt7mj8GOaoM9z1hm0fuBbjtPfokQcpinQ9 +QcV3Cng8ueW9VtQwfOK+DdV2clXr028ZIfZ/E//j1RbGoCDJVoIjqkrfVcYxRpxIT3f 8DBk5bZN5GklMlPdsuShVZ93SEkSYl+S6ORSr6P8HSMikYdOAhipAcT277xxOEZE56Js 4JmFrrZJqn0NkoqUpDuJuhWPH2twfyhQ5MFnqdeCHUahA1NWZuKdz9gZIMC6k1mZ234y Bu7w== 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=dThJ/FYG9mi+kw5kkqtXTXspgSDbN8mx3j4nbRHWacY=; b=a3EyIbJ7pAs/sEPhD/vQ2RO3U/4ANmeHNuwDwsU8rFCI0/unTf2SmMIWAW58CuO7Op IOUb6pSHXIkz2DeBT48AuAkuYc0XUDhwD2hWXwZJHJEkuE+JIvOKGXNL9SU7d7QIMpjD u7R5RsjM+WUAU0gNmvsnbFYEaoerTCFwPKyh4g6ik6MShou/MiCSiCYfv2rMm1WXeppQ mDdOKaeANRL6+W9kOmWZNH5JMIHmNoPculqz3cUGRVhPak5bYROtnnjSIDTem8sHMIwN IRkM7trC14SE/lV1A8vPqHVIkbZBjLqGNnxARMAnLMZOjBWATONY3s6DtLtTxvQQgaHn A1Ng== X-Gm-Message-State: APjAAAWLt+TApzPNYRsHYciDm8MeJptzH1elbsCk++5PuLHeAACZsPqe fmMXtwsPr8CR3YyUzdbWZRuf1w== X-Google-Smtp-Source: APXvYqx74SPgw3gex61nJ/tPpano35BzXlBf87DyAp0OHoEKzTxB5tuXv+4nMsS5Ck9HhPlgUdX2Mw== X-Received: by 2002:aa7:9edd:: with SMTP id r29mr8558332pfq.14.1578538011893; Wed, 08 Jan 2020 18:46:51 -0800 (PST) Received: from [17.192.170.199] ([17.192.170.199]) by smtp.gmail.com with ESMTPSA id s24sm5346385pfd.161.2020.01.08.18.46.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 18:46:51 -0800 (PST) From: Ted Lemon Message-Id: <1596740B-FE4B-4850-AB1A-33E590745B32@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDBDF218-C0EB-474D-8488-74D3BF4E6900" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 8 Jan 2020 18:46:50 -0800 In-Reply-To: Cc: "STARK, BARBARA H" , Eric Rescorla , ADD Mailing list , Mirja Kuehlewind , Vittorio Bertola To: Brian Dickson References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 02:46:55 -0000 --Apple-Mail=_BDBDF218-C0EB-474D-8488-74D3BF4E6900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 8, 2020, at 6:12 PM, Brian Dickson = wrote: >=20 > Concrete examples off the top of my head: > Having policies that can be managed (on managed devices) would be = good.=20 Agree > Having policies that are in some manner tied to network identity or = SSID, in terms of trust. Those are only as valuable as the ability to = securely validate IDs. This is unnecessary. You=E2=80=99re connecting using TLS. Just = validate the server=E2=80=99s cert. The trust establishment process = just configures the server=E2=80=99s identity, you validate the cert, = and Bob=E2=80=99s your uncle. This is not hard. > Policies regarding preference of encrypted vs unencrypted DNS server = (if more than one is available/known). I think this is out of scope. The audience here would be vendors like = Apple, Google, Microsoft, Mozilla, etc. Why would they listen to the = IETF=E2=80=99s pontifications on how best to serve their users? If you = mean configuring hosts via the network with these policies, then you = have a mechanism for overriding trust relationships by an untrusted = network, which we obviously can=E2=80=99t do.=20 If you mean providing a way to securely install provisioning profiles = that implement these policies, then that seems okay. The challenge = here is that I suspect work is being done on this right now by at least = some, if not all, of the vendors I mentioned. I think trying to say how = this should go right now in the absence of much experience isn=E2=80=99t = likely to produce a useful document. > The ability for the client to assess the immediate environment, = including passively or actively interacting with network elements (e.g. = DHCP), and doing various kinds of discovery. This is already covered by the MPvD work (RFC7556, = draft-ietf-intarea-provisioning-domains-10, which is on the January 23 = IESG telechat). --Apple-Mail=_BDBDF218-C0EB-474D-8488-74D3BF4E6900 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 8, 2020, at 6:12 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

Concrete examples off the top of my head:
  • Having policies that can be managed (on = managed devices) would be = good. 
Agree
  • Having = policies that are in some manner tied to network identity or SSID, in = terms of trust. Those are only as valuable as the ability to securely = validate IDs.
This is = unnecessary.  You=E2=80=99re connecting using TLS.  Just = validate the server=E2=80=99s cert.  The trust establishment = process just configures the server=E2=80=99s identity, you validate the = cert, and Bob=E2=80=99s your uncle.  This is not = hard.
  • Policies regarding preference of encrypted vs = unencrypted DNS server (if more than one is = available/known).
I think this is out = of scope.  The audience here would be vendors like Apple, Google, = Microsoft, Mozilla, etc.  Why would = they listen to the IETF=E2=80=99s pontifications on how best to serve = their users?   If you mean configuring hosts via the network with = these policies, then you have a mechanism for overriding trust = relationships by an untrusted network, which we obviously can=E2=80=99t = do. 

If you mean providing a = way to securely install provisioning profiles that implement these = policies, then that seems okay.   The challenge here is that I = suspect work is being done on this right now by at least some, if not = all, of the vendors I mentioned.  I think trying to say how this = should go right now in the absence of much experience isn=E2=80=99t = likely to produce a useful document.

The ability = for the client to assess the immediate environment, including passively = or actively interacting with network elements (e.g. DHCP), and doing = various kinds of discovery.

This is already covered by the MPvD work (RFC7556, = draft-ietf-intarea-provisioning-domains-10, which is on the January 23 = IESG telechat).

= --Apple-Mail=_BDBDF218-C0EB-474D-8488-74D3BF4E6900-- From nobody Thu Jan 9 02:17:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AC812025D for ; Thu, 9 Jan 2020 02:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 7-lUw6eWw8xH for ; Thu, 9 Jan 2020 02:16:56 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1281D12022D for ; Thu, 9 Jan 2020 02:16:55 -0800 (PST) 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 2F2BE6A257; Thu, 9 Jan 2020 11:16:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578565014; bh=blPogNGuRLyx0b3k5fXZqzNM+zRo4Zq80UmL9K6jTwI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=CiNaiX7wOlm8kqLc4etJ7lamjCTRex5y9HO1FmpcxQ0GpVfBkwfB/w20K/AZCkBlb 68OrbVgiNF3KCwN7kFAHndQFhKK9ZDlauH6IBSXs9AZByPepgo85tgSpvGO+Cm0ptq S273ZOjXc1DtZz3cqJh5nyJxjAXyBCkKfG3RLU7FosuS0xKGZLKW+McxRqw6a83RKo hkqsrkgTYIsfG4ugoAm72OeG0TpTNqK3s0AQl3NQA9HCkIH/ZKV/QRpIl8pyxnUXJG c/CMc0qc/ZuOKl0brqyYW6tuX85G1JUiB0IW5fpJBxMrBUDJWn/vObp2xiZfjiXfwU ltFNaxmDi3smA== 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 21DEF3C0447; Thu, 9 Jan 2020 11:16:54 +0100 (CET) Date: Thu, 9 Jan 2020 11:16:53 +0100 (CET) From: Vittorio Bertola To: Stephen Farrell , ADD Mailing list Message-ID: <1235768232.23248.1578565014043@appsuite-gw1.open-xchange.com> In-Reply-To: <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> 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.3-Rev3 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] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 10:16:59 -0000 > Il 09/01/2020 01:07 Stephen Farrell ha scritto: > > I'm not 100% sure, but I strongly suspect that the above > could turn into another set of ratholes if it's not clear > from the charter whether or not insecure or opportunistic > methods for discovery are ruled in or out. Yet, trying to > determine that now is also likely a rathole;-( > > Could there be a way out via something like "Discovery > mechanisms that could disimprove security or privacy in > many existing networks are not in-scope. Mechanisms that > 'do no worse' may (or may not) be acceptable subject to > normal IETF rough consensus, (and it will be rough;-), > processes"? If this means "anything not worse than today should be supported", I think I can live with it (and, in general, I can live with Glenn's proposal, though of course I am not 100% happy with it). But that would require changing your "may (or may not)" :-) The point is that we start from an existing model, we want to upgrade the security of the transport protocol, but some people say: while we are at it, we could also improve the security of the resolver discovery mechanism by not discovering at all, or by only discovering among a set of pre-trusted options, and by preventing the network from applying any policy, as that might be used to attack the user. However, others think that local network policies generally increase the security of the Internet access service, so doing the above will decrease the overall security by removing the network operator's ability to use the DNS to monitor traffic, discover ongoing attacks and prevent connection to infected websites. So they would rather not get the increased security in the discovery mechanism, but also not lose the security provided by the network operator through the resolver; they would like to be able to upgrade the transport protocol without changing the discovery mechanism, except for what is necessary to communicate the existence of an encrypted version of the local resolver. In the end, this is a tradeoff that depends on context and user preferences, and I do not think that we will ever get to agreement on which option is best - not to mention the fact that the choice also impacts on privacy, competition, jurisdiction and other non-technical dimensions, where other non-technical stakeholders will definitely want to have a say. So it would be good if we, as a compromise, agreed that both options are ok, that we need to have technology that can support both of them, and that our arguments on which one is best, or even acceptable, should be better moved outside of the IETF. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Jan 9 03:53:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88D0120835 for ; Thu, 9 Jan 2020 03:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 1V5VIiPygJEN for ; Thu, 9 Jan 2020 03:53:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6718212011E for ; Thu, 9 Jan 2020 03:53:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F3087BE7C; Thu, 9 Jan 2020 11:53:41 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrRl_f2fYcRd; Thu, 9 Jan 2020 11:53:40 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 764F7BE5D; Thu, 9 Jan 2020 11:53:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578570820; bh=B3Dm81OjohXGnmNLdO7CzVBgZV9Ercf4f7sxyFL1SsI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=N9WPjJfXwHaPeGXY9E1uuldOB6CNJ5jZsu0QaydUfJuAygCRJ+OKylSJlRPIuzHQv 6f3FUq11Ri8KbSiW2ubEr7XfNObrYh8LAtvf3yCLCZPMHmlPofayz5xkeZFjlGRgK0 zByBRJ0mY0K+Hr2GkZ0vXndqi++zyVrNMBR6kya0= To: Vittorio Bertola , ADD Mailing list References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> <1235768232.23248.1578565014043@appsuite-gw1.open-xchange.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 9 Jan 2020 11:53:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <1235768232.23248.1578565014043@appsuite-gw1.open-xchange.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="as2itIk6EzN9pupU22vrvWpLuh5HsqhQ0" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 11:53:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --as2itIk6EzN9pupU22vrvWpLuh5HsqhQ0 Content-Type: multipart/mixed; boundary="3FTgJ0TnMjraXmvz6q5gx8Y5P01hOoiW8"; protected-headers="v1" From: Stephen Farrell To: Vittorio Bertola , ADD Mailing list Message-ID: Subject: Re: [Add] A proposed charter for ABCD References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> <1235768232.23248.1578565014043@appsuite-gw1.open-xchange.com> In-Reply-To: <1235768232.23248.1578565014043@appsuite-gw1.open-xchange.com> --3FTgJ0TnMjraXmvz6q5gx8Y5P01hOoiW8 Content-Type: multipart/mixed; boundary="------------BA7169F28B4BB2BEA4B48655" Content-Language: en-US This is a multi-part message in MIME format. --------------BA7169F28B4BB2BEA4B48655 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/01/2020 10:16, Vittorio Bertola wrote: >=20 >=20 >> Il 09/01/2020 01:07 Stephen Farrell ha >> scritto: >>=20 >> I'm not 100% sure, but I strongly suspect that the above could turn >> into another set of ratholes if it's not clear from the charter >> whether or not insecure or opportunistic methods for discovery are >> ruled in or out. Yet, trying to determine that now is also likely a >> rathole;-( >>=20 >> Could there be a way out via something like "Discovery mechanisms >> that could disimprove security or privacy in many existing networks >> are not in-scope. Mechanisms that 'do no worse' may (or may not) be >> acceptable subject to normal IETF rough consensus, (and it will be >> rough;-), processes"? >=20 > If this means "anything not worse than today should be supported", I > think I can live with it (and, in general, I can live with Glenn's > proposal, though of course I am not 100% happy with it). But that > would require changing your "may (or may not)" :-) No, I didn't mean should, I did mean may. Arguing for should here puts us back in rathole territory where we end up endlessly debating which inaccurate abstraction is best, knowing all the time that "none of them" is the correct answer. >=20 > The point is that we start from an existing model, we want to upgrade > the security of the transport protocol, but some people say: while we > are at it, we could also improve the security of the resolver > discovery mechanism by not discovering at all, or by only discovering > among a set of pre-trusted options, and by preventing the network > from applying any policy, as that might be used to attack the user. >=20 > However, others think that local network policies generally increase > the security of the Internet access service, so doing the above will > decrease the overall security by removing the network operator's > ability to use the DNS to monitor traffic, discover ongoing attacks > and prevent connection to infected websites. So they would rather not > get the increased security in the discovery mechanism, but also not > lose the security provided by the network operator through the > resolver; they would like to be able to upgrade the transport > protocol without changing the discovery mechanism, except for what is > necessary to communicate the existence of an encrypted version of the > local resolver. >=20 > In the end, this is a tradeoff that depends on context and user > preferences, and I do not think that we will ever get to agreement on > which option is best - not to mention the fact that the choice also > impacts on privacy, competition, jurisdiction and other non-technical > dimensions, where other non-technical stakeholders will definitely > want to have a say. >=20 > So it would be good if we, as a compromise, agreed that both options > are ok, that we need to have technology that can support both of > them, and that our arguments on which one is best, or even > acceptable, should be better moved outside of the IETF. Two points. "Both are ok" is an unlikely outcome as there are >2 things and each is sometimes ok, sometimes not. 2nd point is that we do already have the insecure discovery model (DHCP/RA) widely deployed. From both of those I would conclude that such a compromise is not a goal, but rather the goal would be to define useful mechanisms with known security and privacy properties, in the full knowledge that people will continue to disagree about how best to deploy those for quite a while yet. Cheers, S. >=20 --------------BA7169F28B4BB2BEA4B48655 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----- --------------BA7169F28B4BB2BEA4B48655-- --3FTgJ0TnMjraXmvz6q5gx8Y5P01hOoiW8-- --as2itIk6EzN9pupU22vrvWpLuh5HsqhQ0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4XFD4ACgkQWrL68XsX K+oFqQ//fpNT1eHjYwILD2dcdDwgqgKkbqVme/SHCFV9PbYqrnZX1T5OB/6bUdZ6 tzEovjM5h4BY5RrLSVdLonljp1QeuGD7/iNu6bz81RMkCHuzHb/QyfoF3YQJOneB jcI0Oeyz+7J/zSjLdVHQAW4pQEpsY1oBkKgGsM8Xev7ym43yvWUjTQqsl9Q7ysz4 /uoqeNIAeUE8GOGibPyWtN3G+xI/XOngod6aDRyWOxU2XpvSgaRaiazO+Tsx/MFp QMRCMp+5gqs1mEYE71dUilGI/lnGvNh/uTF8mKbgwUos5v0+v8HN/ocB/V4b9B8P okRp8G33Vu+TIDwJRwLQ7N2XrXRjig8iNyGzsHRXA8tR6IPd0ihTIgXAhTe+Kt3x 1eQdz4jmCvWXBzAySWTKuXk099BcaFPfPOzcN+fhbxMvY0Ru0wgwv+xOrH1QIT2l tDBCDNN9zUAXx4XnT2IEqEhWxAaWAPl0y1AMxuM5vIvr0rvFAcLi26wey2F3MXWD hfi4/p6I6+nRqakeA7xywlmH8dOa8UHEms080khl5vpm37D8ALa7vfeXfB+di4JT Rntt4QS9TOuYp60DDG/7aDSUNFmbAwba75uulYu5D/XJovQ8XRLOsBR4xMlrJG+M PiOQTkUmqSNgDBTwNDTfVfimu2b6FkNAan80J8eYHC3aDBS0w2Y= =8aZ0 -----END PGP SIGNATURE----- --as2itIk6EzN9pupU22vrvWpLuh5HsqhQ0-- From nobody Thu Jan 9 04:38:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FAF1200C1 for ; Thu, 9 Jan 2020 04:38:18 -0800 (PST) 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 Z2KNDpyXZ59B for ; Thu, 9 Jan 2020 04:38:16 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 7017712001E for ; Thu, 9 Jan 2020 04:38:16 -0800 (PST) Received: from 200116b82ca13800b9ffe619dca4a60c.dip.versatel-1u1.de ([2001:16b8:2ca1:3800:b9ff:e619:dca4:a60c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipX4m-0000yk-39; Thu, 09 Jan 2020 13:38:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> Date: Thu, 9 Jan 2020 13:38:11 +0100 Cc: Eric Rescorla , ADD Mailing list , Vittorio Bertola Content-Transfer-Encoding: quoted-printable Message-Id: <6D2256E1-E652-408E-932C-86938D921D0D@kuehlewind.net> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578573496;078b8b38; X-HE-SMSGID: 1ipX4m-0000yk-39 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 12:38:19 -0000 The case I have in mind is when a managed devices is connected to a = managed enterprise network and a policy is provided to enable or enforce = a local function. Given the device is managed you can probably = pre-install some policies but in this setup you can also preconfigure = your device to know the trusted network and then communicate policies = more dynamically. I guess you can use the same communication mechanism to also distribute = policy at starbucks but I would think your device would by default be = configure to not accept such a policy. I would like the first case to be considered in group working on DNS = discovery. I actually don=E2=80=99t think it will be hard to do so by = e.g. adding additional information to the PvD. If there is a way to = exclude the second case (where the same protocols is used on unmanaged = networks) I don=E2=80=99t know but I guess there is an easy way to have = a local device policy to prohibit that. So I don=E2=80=99t think we have = to decide about the policies itself at this point but I think a = mechanism to communicate some policy locally is important for deployment = of a more adaptive DNS. Mirja > On 8. Jan 2020, at 18:54, Ted Lemon wrote: >=20 > On Jan 8, 2020, at 9:03 AM, Mirja Kuehlewind = wrote: >> I also support to keep the part of communicating local policy as = currently in the proposed charter. >=20 > This statement contains an embedded assumption that you may not be = aware of: that it makes sense for the network to communicate resolver = configuration policy to clients. I don=E2=80=99t think this is an = assumption that we generally agree on. >=20 > The usual counterexample given is that I definitely don=E2=80=99t want = Starbucks to tell me what resolver configuration policy I must use. We = tend to go around and around on this, and it=E2=80=99s not something we = can ever agree on. I think this is a big part of ekr=E2=80=99s reason = for saying we shouldn=E2=80=99t put this in the charter, and I agree = with that. >=20 > It could make sense to make a list of possible policies that could be = configured on a host, and talk about how to address those policies. One = of those policies could be =E2=80=9Ctrust what the network says.=E2=80=9D = This would make sense on infrastructure devices. However, even in = this case it would make sense to have a way to actually establish trust, = and not just assume trust. E.g., for Thread networks, there is a = commissioning process. If we wanted a Thread device to use DoH (not = clear we want that, but just as an example), then the trust = establishment process could be done automatically when the device is = commissioned onto the network. >=20 > So practically speaking, I don=E2=80=99t actually see any reason why = we=E2=80=99d ever want to encourage a protocol that would allow the = network to replace a trusted resolver configuration with an untrusted = resolver configuration. And the problem seems to be that some people = participating in this discussion, whether out of ignorance or = conviction, are in fact arguing that we should put that in the charter. >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Thu Jan 9 04:44:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A444120088 for ; Thu, 9 Jan 2020 04:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 VBmmPbGJkRHi for ; Thu, 9 Jan 2020 04:44:18 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 54FC01200C1 for ; Thu, 9 Jan 2020 04:44:18 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id bd4so2533289plb.8 for ; Thu, 09 Jan 2020 04:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OQTby/E9uQ+lI4gTLT5itzhPHxozIwREvJ9Lcg0HMVY=; b=eUim1pd0g5VNm4451i317HA2wIZIQTro9753YGbwoe3HGoKwDOnXDbJhuFvsgToYvu ShqUpXnvXO8F60h4wz+G1XgiVNqGIIdvsSNRVnPD+PuWtRMPUBqx7CVSTDpS+OZgG6Z7 8VLa1guOEAAS44TNzDtFno8D4XRnjkdn6hnOlKs10vHoTlbE8vAU7y5j8lRCMz9UJo8f nvYgSFbxsa5PaoB25FgqGf0QYFZAUTzYxrYbM8ZGzRbjvHSECbfLDQXV9anZOum+zVK8 XJnXl8Xxxo5yxW5to75UGCrqZ2/3Apw+rhfV3cocyFC3DwGDWk108vT/Ff2Luq4Icoxt UrbQ== 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=OQTby/E9uQ+lI4gTLT5itzhPHxozIwREvJ9Lcg0HMVY=; b=C2Iy34qN9NaPxR+zYT/XGQfTvThPjA1Wcgn0dnBKMMBwox04XHmy9NVijV9EjaN4lS BjcbDxFUuQty9QBC3UAMbVwihYvUfG5EpfRwUv27IeTGj6937i+Q91rV5aT6TdQquLsm 8pmtp5XUjFOupu5xCgbrFSXr2qPV509FmPgUgAX5kiIpMwknpXONgBhhZr0ywSSTchZC kw0LDtKToRXHL1/q9/uTf/Uec/AW7+hr0R7gdEE2UFWGNOraN31axGQlHvu5MULkeOnR RxobIS/Qt9FugW/Fhirha8SEdmENXochghAk0DHxQFojp0PqXLJMzIxKS46lGEzFz7wV T67Q== X-Gm-Message-State: APjAAAU1E2eGknNGihRPg47huFETgcB4lrTr2g/6JNqPCx78GOhe6QMC 4Gd1WXdI636DYhV9hfFfpO23gA== X-Google-Smtp-Source: APXvYqxF1u8QOdMKMZxqGF4J8TluDfCeUvKosjSaSbhQdX/ClkmFDe6K1JUAzkhtlLXEbwApXwEVJg== X-Received: by 2002:a17:902:b711:: with SMTP id d17mr10882215pls.162.1578573857791; Thu, 09 Jan 2020 04:44:17 -0800 (PST) Received: from [10.20.3.28] ([12.217.162.130]) by smtp.gmail.com with ESMTPSA id j20sm7263478pfe.168.2020.01.09.04.44.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 04:44:17 -0800 (PST) From: Ted Lemon Message-Id: <631E515A-2A1E-44E7-B3BF-C372BE394093@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_660E9B12-B242-4656-952F-2C9B6F8B9E5C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Thu, 9 Jan 2020 04:44:14 -0800 In-Reply-To: <6D2256E1-E652-408E-932C-86938D921D0D@kuehlewind.net> Cc: Eric Rescorla , ADD Mailing list , Vittorio Bertola To: Mirja Kuehlewind References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <6D2256E1-E652-408E-932C-86938D921D0D@kuehlewind.net> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 12:44:20 -0000 --Apple-Mail=_660E9B12-B242-4656-952F-2C9B6F8B9E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 9, 2020, at 4:38 AM, Mirja Kuehlewind = wrote: > you can also preconfigure your device to know the trusted network and = then communicate policies more dynamically. Yes, but what does that mean? Do you mean that you can configure the = device to accept an un-signed UDP packet configuring its name resolution = setup to point at Do53 servers, even if it=E2=80=99s configured by = default to talk to a DoT server? > I actually don=E2=80=99t think it will be hard to do so by e.g. adding = additional information to the PvD. PvDs are not signed and can=E2=80=99t be authenticated. > I think a mechanism to communicate some policy locally is important = for deployment of a more adaptive DNS. Can you give an example of what such a policy would look like and how it = would make sense to configure it without it being authenticable? --Apple-Mail=_660E9B12-B242-4656-952F-2C9B6F8B9E5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 9, 2020, at 4:38 AM, Mirja Kuehlewind <ietf@kuehlewind.net>= wrote:
you can also = preconfigure your device to know the trusted network and then = communicate policies more = dynamically.

Yes, but what does that mean?   Do you mean that you can = configure the device to accept an un-signed UDP packet configuring its = name resolution setup to point at Do53 servers, even if it=E2=80=99s = configured by default to talk to a DoT server?

I = actually don=E2=80=99t think it will be hard to do so by e.g. adding = additional information to the PvD.

PvDs are not signed and can=E2=80=99t = be authenticated.

I think a mechanism to = communicate some policy locally is important for deployment of a more = adaptive DNS.

Can you = give an example of what such a policy would look like and how it would = make sense to configure it without it being authenticable?

= --Apple-Mail=_660E9B12-B242-4656-952F-2C9B6F8B9E5C-- From nobody Thu Jan 9 04:52:49 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30979120088 for ; Thu, 9 Jan 2020 04:52:49 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W75G0YxbvitO for ; Thu, 9 Jan 2020 04:52:47 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 2496A120073 for ; Thu, 9 Jan 2020 04:52:47 -0800 (PST) Received: from 200116b82ca13800b9ffe619dca4a60c.dip.versatel-1u1.de ([2001:16b8:2ca1:3800:b9ff:e619:dca4:a60c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipXIq-0006wZ-Gf; Thu, 09 Jan 2020 13:52:44 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <631E515A-2A1E-44E7-B3BF-C372BE394093@fugue.com> Date: Thu, 9 Jan 2020 13:52:43 +0100 Cc: Eric Rescorla , ADD Mailing list , Vittorio Bertola Content-Transfer-Encoding: quoted-printable Message-Id: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <6D2256E1-E652-408E-932C-86938D921D0D@kuehlewind.net> <631E515A-2A1E-44E7-B3BF-C372BE394093@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578574367;af9da829; X-HE-SMSGID: 1ipXIq-0006wZ-Gf Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 12:52:49 -0000 > On 9. Jan 2020, at 13:44, Ted Lemon wrote: >=20 > On Jan 9, 2020, at 4:38 AM, Mirja Kuehlewind = wrote: >> you can also preconfigure your device to know the trusted network and = then communicate policies more dynamically. >=20 > Yes, but what does that mean? Do you mean that you can configure the = device to accept an un-signed UDP packet configuring its name resolution = setup to point at Do53 servers, even if it=E2=80=99s configured by = default to talk to a DoT server? Not in general but maybe for certain services. >=20 >> I actually don=E2=80=99t think it will be hard to do so by e.g. = adding additional information to the PvD. >=20 > PvDs are not signed and can=E2=80=99t be authenticated. Some kind of authentication should probably take place when you join the = network already. However, I think that discussion should take place in a = working group and I think there are people that have more expertise here = than I do. >=20 >> I think a mechanism to communicate some policy locally is important = for deployment of a more adaptive DNS. >=20 > Can you give an example of what such a policy would look like and how = it would make sense to configure it without it being authenticable? >=20 From nobody Thu Jan 9 08:37:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEFA1200CD for ; Thu, 9 Jan 2020 08:37:29 -0800 (PST) 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_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=d1ojVefI; dkim=pass (2048-bit key) header.d=comcast.com header.b=k8taFcuQ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=bu4H9hES Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LVT9T09jYiR for ; Thu, 9 Jan 2020 08:37:27 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 9202012001A for ; Thu, 9 Jan 2020 08:37:27 -0800 (PST) Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009GWWeb009544 for ; Thu, 9 Jan 2020 11:37:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=YWpbAescPzZPAh5uAS4pvg923GWQMo5NozELMeA5gqk=; b=d1ojVefIF+lw4+oVjeb2pdhBrHCTDptoQLdOHnXttQCUsfzgxaOSSZD5ED5veehvRcra SDYJG1vEzSPV+IK6Kyrq20ktFtdEf7yVEB3aWoH+TxsfqwhiNmKTPS31evbVqOsWmAHn GA4DTSH7tII2M4ZHGdEpLS0cMXC56W8xzPGmVBq1QSWZTLXt+2nFE3ufd06F0thEvoBp EZWm2TRFj18QsU46ML5QMcFuS6Qgmb32ReCsC3sZGsEDwbP7WTUl7c97TS1JLBBT8RLz FBxgHXzZrZ30S3zvv2/MMZ1JvLlz1Siwq11TIEnavl68mewFw9mWJa2YZSZhKivXOQDl 0A== Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) by mx0a-00143702.pphosted.com with ESMTP id 2xd99xa3r6-188 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 11:37:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578587846; x=2442501446; 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=YWpbAescPzZPAh5uAS4pvg923GWQMo5NozELMeA5gqk=; b=k8taFcuQWf0aEShGRDGT5qMIz7w0ylXZnlMPDX5bXfXaAIMba9zntBnA4zn+rD2r ae+7VmZdL/06F+TOskIJ8mUW9Q60KcUNLieche206Fhf37pNlAllZM76eIFawAXy vHNfTnRvib/gLitfaypOi5Uf+0hRx3bpQ8tJNU5qqXvYi5m0EI7VgHlOy0+xobdv ekRLs4HAzRwGbT9NV18tVubWXpuXXF9W7oCMsFDnkvmSC07fPlY4WYCQ87951wb7 SbCp5yq0YagYMF2EYt5zTuWzO9qZSIhewNrwzA456qCgifmk3HvAcqh+dxF+jN4h 4gj/oPSyfMIkzVLrXHPNzA==; X-AuditID: 60721c4c-849ff70000006b6a-93-5e1756c5d150 Received: from pacdcex47.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 vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 2A.F2.27498.5C6571E5; Thu, 9 Jan 2020 11:37:26 -0500 (EST) Received: from PACDCEX18.cable.comcast.com (24.40.1.141) by pacdcex47.cable.comcast.com (24.40.2.146) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 11:37:24 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX18.cable.comcast.com (24.40.1.141) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 11:37:24 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.100) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 11:37:14 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2146.namprd11.prod.outlook.com (10.174.112.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Thu, 9 Jan 2020 16:37:13 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 16:37:13 +0000 From: "Livingood, Jason" To: Stephen Farrell , Glenn Deen , ADD Mailing list Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxn4xY4kbO21O20CCNiOSwNlBJafhdHSAgADA0wA= Date: Thu, 9 Jan 2020 16:37:13 +0000 Message-ID: <164F7C51-3324-4353-937A-B17CBD996F8B@cable.comcast.com> References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> In-Reply-To: <9c8e9fcf-7a62-d604-a7a3-78c0796457b9@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:cf9:e038:159a:bd7b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17e49033-6687-40dc-6c20-08d795222e65 x-ms-traffictypediagnostic: BN6PR1101MB2146: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(376002)(39860400002)(366004)(199004)(189003)(316002)(86362001)(81166006)(76116006)(2906002)(4744005)(8676002)(66446008)(478600001)(296002)(110136005)(2616005)(186003)(53546011)(6506007)(66946007)(81156014)(6512007)(6486002)(8936002)(71200400001)(33656002)(5660300002)(64756008)(66556008)(91956017)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2146; H:BN6PR1101MB2195.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: OR5rRe4wv9s94YuuukHJbKIHtRTCGztcOwtBCgjmXpsOIyX/9fhxHd680uBzlp7COCTEquD95jGJ/JEoiMgIbHIxWp5q8AgGTiCODa0mz7AUn5vNPsJfUlswse4vjnlWd4scJ3zPbudvX8Zrg5rQbiudduAUNOKuJj6e5QdvQ3przrwGRciejj2zoX1DTwKyX4yBhUxTGm+nGgrg2olwQNCuugHPh82sraKSbEVXpyYIMQxAwHmM31XObS2PjgFphhcSo5u86WmRAN0dmqfcafW+SzJHjvSoSDPSlc+YGAzTcXDFj7RZXw23ULpkKz3AkFaJtbudG+PttscFlsiFxUfcP2gUZULOati/SFS/bADDAzelc9zrV9QxOLcYUEcLQ3NsGcwRJv2ImUWawD2VdfOk2o+wj2xHMCEvIWqfEWOZ5BSw5J/P68jC5CDD8KUL x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fFLwDwuHr1A/rvPHNloP//RmVyyNmiRBZgs9mE8Jub7TIaFKLGLuxysvLa+r8zGaYMMHpoyeKpQBrxCgIL8EqLxiXpX7TRdLwafgHaErnEs7beByTlCQegNR1qYBoDu0KuF3NaOVOD5A5TfjTmnG3EoN7Je6KHt1025zgGs4QQ6ZVgkUJHQTpAYxiBtdGjAxir75m/iQVqkCQUoWAz8OuZ8qUNBUtF24UvLiqaiRCLPhuNf362pBQoLeUFu5ZjtVH83qg7s6HbeLhug7xRv2n2K1+uJdwH35kO3GQg7Sh3icnVRZuEBMl5OKk7YddpNfov4BNxQm3PkhltS+p1UXDg== 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=kwr6kmzbxbdf13w9ancrsELOqMiHyCCChW26jWsF+Lw=; b=ZLXL3Tsjy4am8C3jM4pJPLn+PBEQnMEs76alj58UoOH944xPrqmwUSDVu50UN6kzrLDtjfVZjbl5kXHWtaRNXcGOJmccRZoemqTJllDSeYQyveL93baLPRi3clr2giwcwt7C2OzCdeEHs4TBpb7pc6j2tVUjXsE76PbQtgdqzzUbEkZCZwmaNH6VyZNj9yvevbSlhYKIV9x1HUgXuuXxKiMkiidca/yyvmnJG8takZdz679yHvJymw9bhUwupVFdqfDG+sXlWpv1XkkemC3pY/gUg5quEMC++thoJloS3+NOWTlRkcsgjfQwPjrqDrG3kVopCOMRcSD1Tz1Bka07iA== 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=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kwr6kmzbxbdf13w9ancrsELOqMiHyCCChW26jWsF+Lw=; b=bu4H9hES6WrJGYvVx+5tEuakfvyuPlmMlUOth0kZTwTPY6l44FUJq/GkQAWGvBWA0VCyoH43xKZ+bf5w9PKlRtBzHfwj1IuD3yehK+Kuh1/dIb2aGqNvDXs8uBazzbSNyRVLefwUGtGeQUfIbxvwYuXcmH2NYNFh0jMS7eoEDPc= x-ms-exchange-crosstenant-network-message-id: 17e49033-6687-40dc-6c20-08d795222e65 x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 16:37:13.3960 (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: xDby04Gy6fWFgbxgToI8NllZK79NFbucuz4RX5trSL25K/r05ZD8E1v6j/7bglRjmDFqSAwhYcH0n8/R1I/5jMUq0j+ZcpIAZkrx1w+VEDE= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2146 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: H4sIAAAAAAAAA22SfUhTURjGPbt3d1dxdVqzvdj3rKComWW2wqw/LBYYlkFQkHnDk1/Lxd2S DJSJSDU1pMyakbOpaFErstYKM5LsExJFyzSNObEvrSj8iGnm3V0Q5Pnr97zv8z7nPXBYSnGC CWXTMk2Ez+T0aiaITjJu1656skeVuLo4D2knXzoYbU9DDdKef/BatoXSXS/sYHT3yntkuurq X5Kd1D4zijal8oQzxZJDJNNIYoIW/XeiD5JDBp5s5Xh9dgLRE256m+BMJvq0LMKHTxsTPm1O kkWS6nD/REdKZces7uu0GY0zFsSygCPhcd46CwpiFfiRBEqetspEcQ+BvfKVxIICp0Q7goIy g9hoRlDyoJcRRZkEBvpu+oUbgdfh8Y0wOAp6LrdTAiuxETyeJh/Pxhqov3SOFuvhUPrY5ueN 0GoeYgSm8RJ4/3BEIuwnx7FQ3xgm5jsRPDtT6csPxJvAWfxBJjDCc2D0xTVfncIq6Oq3+Rgw huqGFkrkEPjk+S0VOGTq3oG3LlqcTYYqi93vXw/DX6sYkedDm60QibwD2lrs/pyVYB0YpEU2 wKT9gn92GXQOnvR75sFLm1cqLA3YQsPw0+++xyhwOgx1xIieBXC12E2XoMjyf9Yun3JReDnc uB8ulnXwq3uMEnkxlBa6ZQLL8Sx4bu2nK5H0KgreEKWJiIjUrNFq1kfdQsL35OfFudCPMl0T wixSB8tro1WJCimXZcw+3ISApdRKeXPnnESFPJnLPk54wwH+qJ4Ym9Bcllar5OnfxvcrcApn IhmEHCH8366EDQw1o80TnXUfR0++KTw98u7Olyfe3TlZjxobJqzNMd5Xyjgn2jIynhDt8o5d rO3NM3QXFQeo7qbkbFvqWJlcX1NnyT17Izb/8GYz6rN35UpmbPxs6MgJuxLPODVFsjf5XaeK DDMKclNcGbv2XiGTGbqAioU1yopPpbdpF147ER/weiajpo2pXMQKijdyfwB1QTDLmgMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_03:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 16:37:29 -0000 T24gMS84LzIwLCA3OjA3IFBNLCAiQWRkIG9uIGJlaGFsZiBvZiBTdGVwaGVuIEZhcnJlbGwiIDxh ZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZT4gd3JvdGU6DQo+ICBDb3VsZCB0aGVyZSBiZSBhIHdheSBvdXQgdmlhIHNvbWV0aGluZyBsaWtl ICJEaXNjb3ZlcnkNCiAgICBtZWNoYW5pc21zIHRoYXQgY291bGQgZGlzaW1wcm92ZSBzZWN1cml0 eSBvciBwcml2YWN5IGluDQogICAgbWFueSBleGlzdGluZyBuZXR3b3JrcyBhcmUgbm90IGluLXNj b3BlLiBNZWNoYW5pc21zIHRoYXQNCiAgICAnZG8gbm8gd29yc2UnIG1heSAob3IgbWF5IG5vdCkg YmUgYWNjZXB0YWJsZSBzdWJqZWN0IHRvDQogICAgbm9ybWFsIElFVEYgcm91Z2ggY29uc2Vuc3Vz LCAoYW5kIGl0IHdpbGwgYmUgcm91Z2g7LSksDQogICAgcHJvY2Vzc2VzIj8NCg0KW0pMXSBJIHRo aW5rIHdlJ2xsIGp1c3Qga2VlcCBkZWJhdGluZyB3aGF0IGFsbCB0aGF0IG1lYW5zLiBTbyBJIGFn cmVlIHdpdGggR2xlbm4gdG8gbGVhdmUgaXQgc2ltcGx5IGFzIGRpc2NvdmVyeSBhbmQgc2VlIHdo YXQgSS1EcyBlbWVyZ2UgaW4gdGhlIFdHIGFuZCBkZWJhdGUgdGhlIHNwZWNpZmljcyBvZiB0aG9z ZSBkb2N1bWVudHMgcGVyIHVzdWFsIElFVEYgcHJvY2Vzcy4NCg0KDQo= From nobody Thu Jan 9 08:44:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E06012007C for ; Thu, 9 Jan 2020 08:44:26 -0800 (PST) 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_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=GQTIc+Ck; dkim=pass (2048-bit key) header.d=comcast.com header.b=PRIhunTW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=T37GSuBq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH6XEHg_J5Rd for ; Thu, 9 Jan 2020 08:44:24 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 894CD120019 for ; Thu, 9 Jan 2020 08:44:24 -0800 (PST) Received: from pps.filterd (m0184891.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009GWl9O005087 for ; Thu, 9 Jan 2020 11:44:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=8gCkolNAxfDxMylixI8ecN5k8ZEOqdqTVdhT6DTQZkg=; b=GQTIc+Ck7Q81g6hShlXWVF6wDyWZF6vJO0Nz+G6CPF87sPaP9uT3oCmBxGZ5cpa+mCgt 27aoXXV7FYPbhsHUGMFhoTUNZ7lCC7sm9DMr2NIaJ+UVS9OUWlm67DKKFrtueMBD+so3 Yvoc0n4lte3zGbLrdJhal9IMpm/k0UiA4UKYB/RYLBoW/QXFe96pAo+v8NdDxM6N262z vTsYbNJ3CKlyz6P1UIrLwx2JAkg0sYFoP+pkbSGWt5ngGB2nA2UubCakuu7lN5AcfG1W NX0Xct3oII6WQrD72aaM3knfHtZn5rlFIYfVCWksNU38sDfhTMFOyUd3CBaKkg9W9Tmh 0A== Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) by mx0b-00143702.pphosted.com with ESMTP id 2xdev3h25h-16 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Jan 2020 11:44:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578588263; x=2442501863; 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=8gCkolNAxfDxMylixI8ecN5k8ZEOqdqTVdhT6DTQZkg=; b=PRIhunTWuMWhFA3xR4KD+hGHPR34JcH+9ETmrxalS+Zos7Ngn/WMARAjuxqidXtb OLD1whj2fETx8kO+Y2+lRBN31LwabIos54ZhntTITayH1YYdHEfnEGa3Xd5hHBry qPXF9+maRcqdTZLsKdO2ghVjbQKg5RJkAj8p9YQpLfBWau5IKHRK4fnKNr26d4km oCdF9Cj9sAKfXn+y2n96xIGUHaevpCbD/C20s9MKg7a0aMrqK9y4hkVKpDugu6D4 EGLzSneeUuAQ2bEm9Hwd+zgbYsTen/HBySHtcIJCjfMPby61wLPPGxsRNzng1LoU rutQQ0QoyjOqJG58ZwgWuQ==; X-AuditID: 60721c4b-b83ff70000004741-5c-5e1758673b6d Received: from PACDCEX24.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 1D.94.18241.768571E5; Thu, 9 Jan 2020 11:44:23 -0500 (EST) Received: from PACDCEX42.cable.comcast.com (24.40.2.141) by PACDCEX24.cable.comcast.com (24.40.1.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 11:44:22 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX42.cable.comcast.com (24.40.2.141) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 Jan 2020 11:44:21 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 11:44:12 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2146.namprd11.prod.outlook.com (10.174.112.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Thu, 9 Jan 2020 16:44:11 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 16:44:11 +0000 From: "Livingood, Jason" To: "STARK, BARBARA H" , 'ADD Mailing list' Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxiSjqBx1on+MFkGbIM7jEmyOcKfgwL+AgAAhR4CAAAOAgIAAEUmAgAAH8oCAAA5tgIAAPUkAgADtdgA= Date: Thu, 9 Jan 2020 16:44:11 +0000 Message-ID: <5B682191-0638-4711-AE91-40D0626540B3@cable.comcast.com> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2001:558:1438:13:cf9:e038:159a:bd7b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 214f7570-7e84-4235-c64c-08d795232794 x-ms-traffictypediagnostic: BN6PR1101MB2146: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(136003)(396003)(346002)(199004)(189003)(6512007)(6486002)(8936002)(71200400001)(33656002)(66946007)(6506007)(81156014)(66556008)(91956017)(66476007)(5660300002)(64756008)(76116006)(2906002)(4744005)(86362001)(81166006)(66446008)(8676002)(316002)(186003)(478600001)(2616005)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2146; H:BN6PR1101MB2195.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: KAw7cd8r+UP+/v3ia65lhN7f+On41R+Lts/ZTG4rbryR9KAZCKfcPoOwtbEBME93zHXm+1BjmSn+3qcM5Ldn3Zwt9hmVk0LO5gfd5MEJPQvd67gmAuMHOGVNg/8KvUx7EGLMKtd8EM8BqatnR7/OLoCApq9YXlsEuC3geimSeBWqjF2YTdpUzL1pxgx8ImV7XK3PKTUagglw6ARKWrg78pVlFzctmoSd0uAbJkCIx7oQQkH7k8C6kEPdYki92pVoQAa0BZyCjG7CuTrpnDZBlfEq+Oeki2XDjyLQ30onORir9qWA1bx5vizQ7diRxXRZDDshoG3Tdac+EHbT978mn8DmJ7P8SSP1gmqnBDom+Tw/HvkpIrH9RogH2RHlvp+3k5ahM6E/ig3EU4Dr0JLlb5WLkiJCnt67Auman7Bc6bhnGqf5EhjbOkcKwSMaTYYE x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IaRETEnk8TUnE1wX40bKTkwD4tBpp9o+ugCP5xF90TXbV9gpFPiQeo0NT7eqHMhNibMBjAKOIVP0rYQkegqVA3ujqHH+aUjuF0ltNcUSqi7Rb0KR/gfXvzHM0UBPLaGhQldaItzPd8W1gPWxeuQORMGSzGomC0hZqj+Q3evpMcd5Nizoa8z4cPGYN8ELIAbUdx9rN1N0neiCB1bCR0Kk5ekdObuWQQTKg4ezgXYOhR/8fUaVHL7fOCV7RxPgQy3uEhFXWml3SloDPZiQk1G1iv2I5sH46oo9v2Xt39jyvbnqHO4mJIsU3sfa3EehwrMlWdg5qL7MEpC0wYkg8w6/fQ== 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=D+g4ZuB6qP+v/uh1KVifm4s0i3dDAItk8CvqCbOelKg=; b=hJ3QbzwXEqlGM+ba1X+AVdwaJTA/oDkQWPw14hw6sDUKhgbJsjgekf+d0gSc/DMRwrIR2oROAIwcEJj3QGZLydywdPEJFuBotqmrH68kJiLt1l4bxdm2LTZ7Q7H60bX76xQAqBfxmBjcaMIzivVKcGlC2r/nF5ZLzeZ3VXMCQ27Mzbyx7tKhiGbkE2X7Ie8Xk+TqrLu+JihnhxLU4k5onJ9e+F6BQH0HmFFckDLGs2/k4HTfH9mU501Sq1l4F23PHAv2wxBJRoO5V4dO7HXVeKm+RnC9gOFahRfE9m/aReA7pQj/P6Q/I7kCKzxcBlS2EEv/ZRWbYg8ZFg6n+Ve3ew== 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=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D+g4ZuB6qP+v/uh1KVifm4s0i3dDAItk8CvqCbOelKg=; b=T37GSuBqm3xx1N/CZffoQ84sYIy3LVowWC7u5YWav18ZDcNXkEYCrxOVlyBrCGubkZoznqZDuwf8z3Ts1iM+mUyPIM+/cUaZoojPP99thQl8rUJ/gZ7dAuwJ2OsnXvMLFtyIX8HOTjfisnAAd7JuaGCxZiZD99gVxD9VyB4bjMM= x-ms-exchange-crosstenant-network-message-id: 214f7570-7e84-4235-c64c-08d795232794 x-ms-exchange-crosstenant-originalarrivaltime: 09 Jan 2020 16:44:11.4481 (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: xMzOlrY6GgAcHZtrxweLnW5JNDbAJjFaBhul3nppm0Pxesn5WFVhX3MIgeRf5EDYO38xxA2U4qIdkBqp2uvUVKNdhtqov1JhNIEl5DA68Lg= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2146 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <71D1C7A35FA47C419E350ED776A4FF1A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDKsWRmVeSWpSXmKPExsWSUOxpoZseIR5n0NuvbPH/9Do2i0l/fzI6 MHm87J/D6LFkyU+mAKaoBkabkoyi1MQSl9S01LziVDsuBQxgk5Sall+U6ppYlFMZlJqTmohd GUhlSmpOZllqkT5WY/SxmpPQxZTxrv8ua8E/joqlE+cyNjA+4Ohi5OSQEDCR+HzhIFsXIxeH kMBBJom22ecZIZydjBI7+5ezQDhXGCV2TLzHBNIiJHCUUWLeHCEIexqTxNtl4hBFD4E6vv5l B0mwCZhJ3F14hRnEFhHwkug8sw7MFhbQk9g8dyoLRFxfYsqR+VB2ksSEg0/AelkEVCTWde0D s3kFXCQ+fz/CDrHgOYtE0/rdjCAJToEoiQcz5oI1MwqISXw/tQbsOmYBcYlbT+YzQTwnILFk z3lmCFtU4uXjf6wgtijQ4mc3d0D1pkgs7loEVW8u8fXdYjYIW1bi0vxuoF0cQLavxPG5lhBh HYmZz96wQNj5ErcO3oey1SS2XzsPNUZG4vT836wQ9g9miZ2XjUDGCAlkSby9agcRlpNY1fuQ ZQKjySwkR88CqmIW0JRYv0sfIuwhsXHLO0YIW1FiSvdD9lngQBGUODnzCcsCRtZVjDyWZnqG hiZ6RhZ65qabGEFpskjGewfjup/uhxgFOBiVeHgbwsXjhFgTy4orcw8xSnAwK4nwHr0hFifE m5JYWZValB9fVJqTWnyIUZqDRUmcN+v9n1ghgfTEktTs1NSC1CKYLBMHp1QD4xH9Vrf/RtNE +vY0Mkzkd9l09H95zj3exMOzymQfN39S6snZ+vVD/+eJCuKtj74cPy0gol5X+rV/rti8YOsb l2SD9ujJGNtOmLct7vWK4n8flGMqvQLEZy2T/uc19c5uwfWPdjCdO2ah96PyeodjPmOvxc38 lEQh9bPtR38vYooKEGXz2Cd0U4mlOCPRUIu5qDgRAHtQnz6PAwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_03:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 16:44:26 -0000 PiAgICBXaG8gZ2V0cyB0byBkZWZpbmUgInRydXN0ZWQgcmVzb2x2ZXIiPw0KDQpbSkxdIFRydXN0 IGlzIHJlbGF0aXZlLCBzbyBpdCBjaGFuZ2VzIGZyb20gcGVyc29uIHRvIHBlcnNvbiwgY291bnRy eSB0byBjb3VudHJ5LCBjb25zdW1lciB0byBlbnRlcnByaXNlLCBldGMuIFdlIHdpbGwgbmV2ZXIg c29sdmUgdGhpcyBxdWVzdGlvbiBJTU8uIEkgdGhpbmsgdGhpcyBpcyByZWFsbHkgdXAgdG8gZWFj aCBhcHBsaWNhdGlvbiB0byBkZWNpZGUsIHdoaWNoIG1heSBiZSBiYXNlZCBvbiBkaXJlY3QgdXNl ciBwcmVmZXJlbmNlcy9jaG9pY2UsIHNvbWV0aGluZyBiYXNlZCBvbiB0aGUgbmV0d29yayAoZS5n LiBlbnRlcnByaXNlKSwgYXMgcGFydCBvZiB0aGUgcGhpbG9zb3BoeSBvZiB0aGUgYXBwICh3aGlj aCBpcyBtYXliZSB3aHkgdGhlIHVzZXIgY2hvc2UgdG8gdXNlIHRoYXQgYXBwIHZzLiBhIGNvbXBl dGluZyBhcHApLCBvciBhbnl0aGluZyBlbHNlLg0KDQpbSkxdIFBlcmhhcHMgd2UgY2FuIHNpbXBs eSBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBob3cgdG8gcHJvdmlkZSBhIHN0YW5kYXJkcy1iYXNlZCBt ZWNoYW5pc20gdG8gY29tbXVuaWNhdGUgc3RydWN0dXJlZCBkYXRhIHRvIGEgY2xpZW50IGFib3V0 IHRoaW5ncyBzdWNoIGFzIGhvdyBhIHJlc29sdmVyIG9wZXJhdGVzIChlLmcuIEROU1NFQyB2YWxp ZGF0aW5nLCBEb0ggVVJMIG9mIFgsIERPVCBGUUROIG9mIFksIHdoYXRldmVyKS4gSG93IHRoZSBh cHAgd2lsbCBjaG9vc2UgdG8gdXNlIHRoYXQgaW5mb3JtYXRpb24gYW5kIG1ha2UgYSBzZWxlY3Rp b24gZGVjaXNpb24gc2VlbXMgdXAgdG8gdGhlIGFwcC9PUy4NCg0KDQo= From nobody Thu Jan 9 09:03:06 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F6A120875 for ; Thu, 9 Jan 2020 09:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 fnrngA44G39N for ; Thu, 9 Jan 2020 09:02:58 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 DBB62120834 for ; Thu, 9 Jan 2020 09:02:57 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id k3so3502325pgc.3 for ; Thu, 09 Jan 2020 09:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=67IrTT8v2HIWFGT8BQ2BERjRUPyeJii5iFezXMXiw2Q=; b=Mt/dVI/ZkrhsS+SNJ2MJj5rQvPqzFQW1f3z+BGsP2gWwkdtpg5EDxERFIdJAVyhAsB 72b7oMqC6yrw2z2VpjYbwLWM7Phfws+6h1//hgocjtUpr7Na/cuEGuSjZqa/L4njnpiD McxeJF9nuzyCQyMeZY90M9yjbUacalSKIkvl/EGPJVgmWtGIKMtkIjLep2XjfQtxqb9a Pa3C7IZ1/BBVM0fUP1ZIijxRfsIGqYnZ9i5B9yAt+429EQ5W+na2wh4FL7tKyexssUoZ kY5XGIethMpgo8jEFIOVm9Qc6imtjtkWAOERO/ZD2THU4YqkgFVZES7ML9q5rCUKZY3M +lyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=67IrTT8v2HIWFGT8BQ2BERjRUPyeJii5iFezXMXiw2Q=; b=JWCWIS8QFcPACTR7cUyGxFbY+QDfhY/hOW398+meORnzLGIg44RNmuvwHi97uTnbhb Ewh4Dpc5nMH1zI0a9083hWRsjoGToPDYrDkxMX4y8jhAzvY9M+ZWigvuIkA8XHLBPJ9O qt8CN4/4Lk53XLPB8xMiAxkACWK3SFmR6DTYtRypl46Qc38F+j6WN4cZwh3rdyIIfuzJ LvDb0lVWMjMvkHPlFRyNofnOcGK3qGe60oWo4jThtGmGuxT1y/wjfb5kOtk1GGLQS9HT KlEWjmzBxwSHnNTHCYhlgddJkQwIv4qkRnHbLog9SWSIy0iSh6e6ur1VJswDQxlUHpHS GqYg== X-Gm-Message-State: APjAAAVuxte+W4lRLHWbXgEshGPmPddedv1LpHs8FhuvEMyrgkMjsqOs r/XsglZ99Q8C6iHna9VCte66R1pt/Pw= X-Google-Smtp-Source: APXvYqzMFz+4L4FjrmZrV/VBcR08AZCCju3Cp5jU9CuZ+tQPcONvVXsY9jELM1f2K7IbUxWKwqRvSg== X-Received: by 2002:a63:9e12:: with SMTP id s18mr12147779pgd.380.1578589376513; Thu, 09 Jan 2020 09:02:56 -0800 (PST) Received: from [192.168.1.233] (cpe-108-185-101-45.socal.res.rr.com. [108.185.101.45]) by smtp.gmail.com with ESMTPSA id p24sm8584771pff.69.2020.01.09.09.02.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 09:02:55 -0800 (PST) From: "Glenn Deen" To: "ADD Mailing list" Date: Thu, 09 Jan 2020 09:02:53 -0800 X-Mailer: MailMate Trial (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BBFCF0BA-2895-4045-AAC4-F188B87A43E4_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Add] DNC Discovery and Selection - Moving the idea of a new WG forward X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 17:03:04 -0000 --=_MailMate_BBFCF0BA-2895-4045-AAC4-F188B87A43E4_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Please forgive the duplicate posting of this to the ADD list. My original posting yesterday was buried in the “A proposed charter for ACBCD” and I received the excellent advice from a number of people that this might get better notice if it was reposted to a fresh thread with some added new material. The Essence of the original post was: Instead of trying to be both prescriptive and proscriptive in a charter for ABCD let’s step back, set the high level goals and boundaries for the group and then let the contributors, WG chairs, and ADs do their parts to contribute the ideas, manage the group, and oversee the direction and process adherence respectively. Forgive my use of the fancy words “Prescribe” and “Proscribe”, I spent some time thinking how to describe what was triggering much of the concern and discussion around the various WG proposals and these two things seemed to be the major contributor. For the non-english speakers on the list: Prescribe is telling people how they are to do something; Proscribe is telling people how they cannot do something. If this was a topic area where only a small number of contributors, with few reviewers paying close attention to the work there is a very real possibility that such a small group could run amok. However, in the case of Discovery and Selection of Resolvers by DNS Clients we have (1) a diverse set of interested parties that have already contributed drafts and are likely to contribute more; (2) a robust and diverse set of commenters and reviewers; and (3) a good number of parties that are working on both implementations and deployments. With so much activity and interest it’s very unlikely the WG could run amok especially with well chosen chairs and the ever watchful eye and helpful guidance of the ADs. This doesn’t mean there aren’t potential dragons lurking in the focused areas of Discovery and Selection, but the high level of diverse engagement we have is an ideal one for the workgroup to thrive and succeed. In other words, tell the WG what its high level goal is and then trust the people and the IETF process to do the work and get it right. Here is a simpler WG Charter proposal: Produce mechanisms which will enable a DNS Client to discover the recursive resolvers available to it in the network environment it is connected to, with recognition that the network environment for a DNS Client can change overtime such as a device moving between different networks environments such as a home, an office, and a public space such as a cafe, or others as identified by the WG. Produce a framework where the DNS Client can obtain the information needed by the client to select the DNS resolvers it chooses to use. The WG will limit its work to the technical aspects of discovery and the technical aspects of the selection framework for DNS/53, DoH, and DoT operational environments. The WG is not chartered to work on non-technical areas such as policy, except the conveyance of whatever policy information in the selection framework to enable DNS Clients to make their selection. The WG is not charted to work on security, or privacy problems beyond those essential to Discovery or Selection. And we call it DNS-DS (DNS Discovery and Selection) To the questions of… 1. Is X aspect of discovery included - the answer is it’s up to the WG. 2. Is Y element of information to be made available to the client? - the answer is it’s up to the WG. 3. Will the group specify what the clients preferences are? - No, this is out of scope. Mechanisms to deliver information to the client are included, but what the client chooses to do as a result is out of scope. 3. Is the extended privacy of transactions and data logs and transactions in the recursive resolving DNS architecture included - Broad answer: No because such things are not about discovery or selection - Narrow answer: Except where such knowledge of such behavior is needed by clients to make and selection, and for the case of selection - then it’s up to the WG. There is 10 weeks until IETF107 and 29 week until IETF108. I’d prefer to spend that time working on these problems than trying to get the perfect charter perfect. -Glenn Deen — original post - I’ve been working on this note for the last 2 days, going back and forth trying to layout a path forward for ADD/ABCD. I’m sure it is not perfect, but you wait for perfection you’ll never move productively forward. Please try to be kind when responding. As it standands currently there are two ABCD charter proposals [1] https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw and [2] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w which have the same top level goal: Discovery and Selection of Resolvers by a DNS Client, but they differ in the specific description of deliverables as well as what they prescribe as the starting point and approach. For full disclosure I was a contributor to (1), but that said I see common goals exist across both which gives me hope. The discussion seems to be stuck with people talking past one another, and a lack of focus on how to move forward. My intention is to try to break that pattern by first breaking down why this is even being discussed and then proposing a path forward. Why we are discussing this ———————————— The real world deployment of the changes driven by Encrypted DNS technologies like DoH and DoT and other changes being proposed like Adaptive DNS and Ubiquitous DNS are being the need for Discovery and Selection of DNS Resolvers. So this is neither an academic exercise nor engineers wanting to change things for the sake of change. The need for Discovery and Selection of Resolvers by a DNS Client has been raised on this list, at microphones, and on other lists such as the EDDI Encrypted DNS Deployment Initiative list and meetings. The input has come from a broad set of contributors that come from a wide cross section of the participants who care about DNS including major browser makers, OS makers, network operators, DNS operators, and others from enterprises, and dare I say even it, from users too. We’ve even had a number of drafts submitted to DNS OPs and DNS Priv So while I acknowledge that there is not 100% agreement on the above, as if there ever is in such things, there does seem to a tremendous amount of interest in the need for Discovery and Selection, as well as a broad and diverse set of contributors wanting to work on it, and we have groups actually working on building and deploying solutions as well. The conclusion is that there is a community of interest, contributors, and adopters here, and the work is going to be done somehow and somewhere which leaves the question for the IETF being the outstanding questions of what part of that work is to be done with the IETF, what exactly is the scope of that work? Having caught up on the proposals, suggestions, and comments it seems that perhaps the biggest barrier is in trying to create the optimized charter of deliverables, scope, and with prescriptive and proscribed approaches that satisfies the various diverse views while also trying to proscribe in how the WG shall do it. Essentially the various drafts have elements of trying preemptively manage the WG’s work before the WG has a change to meet and engage. Each of the proposals cites one or more specific drafts as the basis for the work, and that in turn seems to be causing a lot of the debate as that level of prescription to the WG sets proponents of the other approaches off. Getting back to making progress ——————————————— I’d suggest that perhaps the approach of being too proscriptive in the charter is not going to succeed and instead of trying to create the optimal charter that assuages the various wants, fears, and hopes that people have put out on the list, that we alternatively it approach it a simpler way. - a key part of which will involve trusting the IETF process and ourselves to work together to consciously do the right thing. Instead of trying to put just the right words into the charter have upfront cover every possible aspect and contingency as if the charter itself was code, we do the following: (1) Create a charter with a clear, yet simple goals. (2) Create simple clear boundaries. (3) Let the WG members do the work of bringing together the various proposals and discuss and work through the use-cases, needs, and technical issues. Do not be overly detailed or proscriptive in the charter, and let it organically evolve as needed via the WG participants and under the WG Chairs management and oversight of the ADs. Part of the problems in the previous attempts has been trying to skip past this hard work by being proscriptive in the charter. This has resulted in non-productive back and forth on the list instead of focused discussion on the specifics in drafts. (4) Trust in the IETF process and give the chance for the WG Chairs and the ADs to work together to manage the WG activity and to keep it on track. Give the chairs the mission and ability, under the ever watchful and wise guiding hands of the ADs, to manage the WG toward the focused goal delivering the Discovery and Selection functionality that DNS Clients need in deployments. (5) Remove any boiler plate or unneeded assertions, comments, guidance, as well as anything that it obvious. A great example of something obvious is saying in the charter that the WG will coordinate with other groups or security area, because quite obviously they will, for there isn’t any other choice is the WG is actually going to produce documents that have a hope of getting approval in the IESG. If we did that then this is how this 5 points could play out: Clear, yet simple goal such as: The WG will work on the problems of Discovery and Selection of Recursive Resolvers by DNS Clients. The goals of the group are to: (1) Produce mechanisms which will enable a DNS Client to discover the recursive resolvers available to it in the network environment it is connected to, with recognition that the network environment for a DNS Client can change overtime such as a device moving between different networks environments such as a home, an office, and a public space such as a cafe, or others as identified by the WG. (2) Produce a framework where the DNS Client can obtain the information needed by the client to select the DNS resolvers it chooses to use. Simple clear boundaries, such as: The WG will limit its work to the technical aspects of discovery and the technical aspects of the selection framework for DNS/53, DoH, and DoT operational environments. The WG is not chartered to work on non-technical areas such as policy, except the conveyance of whatever policy information in the selection framework to enable DNS Clients to make their selection. The WG is not charted to work on security, or privacy problems beyond those essential to Discovery or Selection. Let the WG do the work This means the WG won’t be told via that charter what WG drafts or architectures it must start from. The WG would open the floor to drafts for consideration that cover both proposals for Discovery or Selection, As well a problem statement drafts and use-case drafts that would present the functional needs and considerations that the Discovery mechanisms, and Selection framework would need to satisfy. This will be drive the discussion hopefully to be technical and about specifics and get away from the ADD list issues. Trust in the IETF process Hopefully the ADs will appoint WG chairs that are willing to stay above the fray and focus on managing the WG process. Remove any boiler plate or unneeded assertions, comments, guidance, as well as anything that it obvious. See the above proposal under point (1) Clear, yet simple goal. This is a technical working group that will be run with hands on supervision. The charter isn’t a legal statue that we need to avoid legal loopholes in, it’s not going to litigated, and the AD’s and IESG can always Choose to refine the mission or even close the WG if it goes off the rails. We have a tried and proven process to manage this sort of work; Let’s use it and get to work. This all comes together in the shaved down WG charter proposal: The WG will work on the problems of Discovery and Selection of Recursive Resolvers by DNS Clients. The goals of the group are to: (1) Produce mechanisms which will enable a DNS Client to discover the recursive resolvers available to it in the network environment it is connected to, with recognition that the network environment for a DNS Client can change overtime such as a device moving between different networks environments such as a home, an office, and a public space such as a cafe, or others as identified by the WG. (2) Produce a framework where the DNS Client can obtain the information needed by the client to select the DNS resolvers it chooses to use. The WG will limit its work to the technical aspects of discovery and the technical aspects of the selection framework for DNS/53, DoH, and DoT operational environments. The WG is not chartered to work on non-technical areas such as policy, except the conveyance of whatever policy information in the selection framework to enable DNS Clients to make their selection. The WG is not charted to work on security, or privacy problems beyond those essential to Discovery or Selection. ** that’s it folks ** And we call it DNS-DS (DNS Discovery and Selection) Are there interesting topics and aspects of DNS being left out of this? Absolutely, and for those there is DPRIV and DNS-OPS etc. They remain the places to discuss those other things as appropriate. This WG is just about D&S. Time is ticking away and IETF107 in Vancouver is now only 10 weeks away. We could spend 10 more weeks talking past one another, or we could settle on what needs to be done, hopefully get the ADs/IESG to buy in, and get down to work. -Glenn Deen [1] https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw [2] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w --=_MailMate_BBFCF0BA-2895-4045-AAC4-F188B87A43E4_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please forgive the duplicate posting of this to the ADD l= ist. My original posting yesterday was buried in the =E2=80=9CA proposed = charter for ACBCD=E2=80=9D and I received the excellent advice from a num= ber of people that this might get better notice if it was reposted to a f= resh thread with some added new material.

The Essence of the original post was:

Instead of trying=
 to be both prescriptive and proscriptive in a charter for ABCD let=E2=80=
=99s step back,
set the high level goals and boundaries for the group and then let the co=
ntributors, WG chairs,
and ADs do their parts to contribute the ideas, manage the group, and ove=
rsee the direction and
process adherence respectively.

Forgive my use of the fancy words =E2=80=9CPrescribe=E2=80= =9D and =E2=80=9CProscribe=E2=80=9D, I spent some time thinking how to de= scribe what was triggering much of the concern and discussion around the = various WG proposals and these two things seemed to be the major contribu= tor. For the non-english speakers on the list: Prescribe is telling peop= le how they are to do something; Proscribe is telling people how they can= not do something.

If this was a topic area where only a small number of con= tributors, with few reviewers paying close attention to the work there is= a very real possibility that such a small group could run amok. However= , in the case of Discovery and Selection of Resolvers by DNS Clients we h= ave (1) a diverse set of interested parties that have already contributed= drafts and are likely to contribute more; (2) a robust and diverse set o= f commenters and reviewers; and (3) a good number of parties that are wo= rking on both implementations and deployments. With so much activity a= nd interest it=E2=80=99s very unlikely the WG could run amok especially w= ith well chosen chairs and the ever watchful eye and helpful guidance of = the ADs. This doesn=E2=80=99t mean there aren=E2=80=99t potential drag= ons lurking in the focused areas of Discovery and Selection, but the high= level of diverse engagement we have is an ideal one for the workgroup to= thrive and succeed.

In other words, tell the WG what its high level goal is a= nd then trust the people and the IETF process to do the work and get it r= ight.

Here is a simpler WG Charter proposal:

 Produce mechanis=
ms which will enable a DNS Client to discover the recursive resolvers ava=
ilable to
 it in the network environment it is connected to, with recognition that =
the network environment for
 a DNS Client can change overtime such as a device moving between differe=
nt networks environments
 such as a home, an office, and a public space such as a cafe, or others =
as identified by the WG.

 Produce a framework where the DNS Client can obtain the information need=
ed by the client to select
 the DNS resolvers it chooses to use.

 The WG will limit its work to the technical aspects of discovery and the=
 technical aspects of the
 selection framework for DNS/53, DoH, and DoT operational environments.

 The WG is not chartered to work on non-technical areas such as policy, e=
xcept the conveyance of
 whatever policy information in the selection framework to enable DNS Cli=
ents to make their selection.

 The WG is not charted to work on security, or privacy problems beyond th=
ose essential to Discovery or Selection.


 And we call it DNS-DS (DNS Discovery and Selection)

To the questions of=E2=80=A6

  1. Is X aspect of discovery included

    • the answer is it=E2=80=99s up to the WG.

  2. Is Y element of information to be made av= ailable to the client?

    • the answer is it=E2=80=99s up to the WG.

  3. Will the group specify what the clients p= references are?

    • No, this is out of scope. Mechanisms to deliver information to the c= lient are included, but what the client chooses to do as a result is out = of scope.

  4. Is the extended privacy of transactions a= nd data logs and transactions in the recursive resolving DNS architecture= included

    • Broad answer: No because such things are not about discovery or selec= tion
    • Narrow answer: Except where such knowledge of such behavior is needed= by clients to make and selection, and for the case of selection - then i= t=E2=80=99s up to the WG.

There is 10 weeks until IETF107 and 29 week until IETF108= =2E I=E2=80=99d prefer to spend that time working on these problems tha= n trying to get the perfect charter perfect.

-Glenn Deen

=E2=80=94 original post -

I=E2=80=99ve been working on this note for the last 2 day= s, going back and forth trying to layout a path forward for ADD/ABCD. I=E2= =80=99m sure it is not perfect, but you wait for perfection you=E2=80=99l= l never move productively forward. Please try to be kind when responding.=

As it standands currently there are two ABCD charter prop= osals [1] https://mailarchive.ietf.org/a= rch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw and [2] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4= G9ZbCo_w which have the same top level goal: Discovery and Selection = of Resolvers by a DNS Client, but they differ in the specific description= of deliverables as well as what they prescribe as the starting point and= approach. For full disclosure I was a contributor to (1), but that said = I see common goals exist across both which gives me hope.

The discussion seems to be stuck with people talking past= one another, and a lack of focus on how to move forward. My intention is= to try to break that pattern by first breaking down why this is even bei= ng discussed and then proposing a path forward.

Why we are discussing this
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94

The real world deployment of the changes driven by Encryp= ted DNS technologies like DoH and DoT and other changes being proposed li= ke Adaptive DNS and Ubiquitous DNS are being the need for Discovery and S= election of DNS Resolvers. So this is neither an academic exercise nor en= gineers wanting to change things for the sake of change.

The need for Discovery and Selection of Resolvers by a DN= S Client has been raised on this list, at microphones, and on other lists= such as the EDDI Encrypted DNS Deployment Initiative list and meetings. = The input has come from a broad set of contributors that come from a wide= cross section of the participants who care about DNS including major bro= wser makers, OS makers, network operators, DNS operators, and others from= enterprises, and dare I say even it, from users too.

We=E2=80=99ve even had a number of drafts submitted to DN= S OPs and DNS Priv

So while I acknowledge that there is not 100% agreement o= n the above, as if there ever is in such things, there does seem to a tre= mendous amount of interest in the need for Discovery and Selection, as we= ll as a broad and diverse set of contributors wanting to work on it, and = we have groups actually working on building and deploying solutions as we= ll.

The conclusion is that there is a community of interest, = contributors, and adopters here, and the work is going to be done somehow= and somewhere which leaves the question for the IETF being the outstandi= ng questions of what part of that work is to be done with the IETF, what = exactly is the scope of that work?

Having caught up on the proposals, suggestions, and comme= nts it seems that perhaps the biggest barrier is in trying to create the = optimized charter of deliverables, scope, and with prescriptive and prosc= ribed approaches that satisfies the various diverse views while also tryi= ng to proscribe in how the WG shall do it. Essentially the various drafts= have elements of trying preemptively manage the WG=E2=80=99s work before= the WG has a change to meet and engage. Each of the proposals cites one = or more specific drafts as the basis for the work, and that in turn seems= to be causing a lot of the debate as that level of prescription to the W= G sets proponents of the other approaches off.

Getting back to making progress
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

I=E2=80=99d suggest that perhaps the approach of being to= o proscriptive in the charter is not going to succeed and instead of tryi= ng to create the optimal charter that assuages the various wants, fears, = and hopes that people have put out on the list, that we alternatively it = approach it a simpler way. - a key part of which will involve trusting th= e IETF process and ourselves to work together to consciously do the right= thing.

Instead of trying to put just the right words into the ch= arter have upfront cover every possible aspect and contingency as if the = charter itself was code, we do the following:

(1) Create a charter with a clear, yet simple goals.

(2) Create simple clear boundaries.

(3) Let the WG members do the work of bringing together t= he various proposals and discuss and work through the use-cases, needs, a= nd technical issues. Do not be overly detailed or proscriptive in the cha= rter, and let it organically evolve as needed via the WG participants and= under the WG Chairs management and oversight of the ADs. Part of the pro= blems in the previous attempts has been trying to skip past this hard wor= k by being proscriptive in the charter. This has resulted in non-producti= ve back and forth on the list instead of focused discussion on the specif= ics in drafts.

(4) Trust in the IETF process and give the chance for the= WG Chairs and the ADs to work together to manage the WG activity and to = keep it on track. Give the chairs the mission and ability, under the ever= watchful and wise guiding hands of the ADs, to manage the WG toward the = focused goal delivering the Discovery and Selection functionality that DN= S Clients need in deployments.

(5) Remove any boiler plate or unneeded assertions, comme= nts, guidance, as well as anything that it obvious. A great example of so= mething obvious is saying in the charter that the WG will coordinate with= other groups or security area, because quite obviously they will, for th= ere isn=E2=80=99t any other choice is the WG is actually going to produce= documents that have a hope of getting approval in the IESG.

If we did that then this is how this 5 points could play = out:

Clear, yet simple goal such as:

The WG will work on the problems of Discovery and Selecti= on of Recursive Resolvers by DNS Clients.

The goals of the group are to:

(1) Produce mechanisms which will enable a DNS Client to = discover the recursive resolvers available to
it in the network environment it is connected to, with recognition that t= he network environment for
a DNS Client can change overtime such as a device moving between differen= t networks environments
such as a home, an office, and a public space such as a cafe, or others a= s identified by the WG.

(2) Produce a framework where the DNS Client can obtain t= he information needed by the client to select
the DNS resolvers it chooses to use.

Simple clear boundaries, such as:

The WG will limit its work to the technical aspects of di= scovery and the technical aspects of the selection framework
for DNS/53, DoH, and DoT operational environments.

The WG is not chartered to work on non-technical areas su= ch as policy, except the conveyance of whatever policy
information in the selection framework to enable DNS Clients to make thei= r selection.

The WG is not charted to work on security, or privacy pro= blems beyond those essential to Discovery or Selection.

Let the WG do the work

This means the WG won=E2=80=99t be told via that charter = what WG drafts or architectures it must start from.

The WG would open the floor to drafts for consideration t= hat cover both proposals for Discovery or Selection,
As well a problem statement drafts and use-case drafts that would present= the functional needs and considerations
that the Discovery mechanisms, and Selection framework would need to sati= sfy.

This will be drive the discussion hopefully to be technic= al and about specifics and get away from the ADD list issues.

Trust in the IETF process

Hopefully the ADs will appoint WG chairs that are willing= to stay above the fray and focus on managing the WG process.

Remove any boiler plate or unneeded assertions, comments,= guidance, as well as anything that it obvious.

See the above proposal under point (1) Clear, yet simple = goal.

This is a technical working group that will be run with h= ands on supervision. The charter isn=E2=80=99t a legal statue
that we need to avoid legal loopholes in, it=E2=80=99s not going to litig= ated, and the AD=E2=80=99s and IESG can always
Choose to refine the mission or even close the WG if it goes off the rail= s. We have a tried and proven
process to manage this sort of work; Let=E2=80=99s use it and get to work= =2E

This all comes together in the shaved down WG charter pro= posal:

The WG will work on the problems of Discovery and Selecti= on of Recursive Resolvers by DNS Clients.

The goals of the group are to:

(1) Produce mechanisms which will enable a DNS Client to = discover the recursive resolvers available to
it in the network environment it is connected to, with recognition that t= he network environment for
a DNS Client can change overtime such as a device moving between differen= t networks environments
such as a home, an office, and a public space such as a cafe, or others a= s identified by the WG.

(2) Produce a framework where the DNS Client can obtain t= he information needed by the client to select
the DNS resolvers it chooses to use.

The WG will limit its work to the technical aspects of di= scovery and the technical aspects of the selection framework
for DNS/53, DoH, and DoT operational environments.

The WG is not chartered to work on non-technical areas su= ch as policy, except the conveyance of whatever policy
information in the selection framework to enable DNS Clients to make thei= r selection.

The WG is not charted to work on security, or privacy pro= blems beyond those essential to Discovery or Selection.

** that=E2=80=99s it folks **

And we call it DNS-DS (DNS Discovery and Selection)

Are there interesting topics and aspects of DNS being lef= t out of this? Absolutely, and for those there is DPRIV and DNS-OPS etc. = They remain the places to discuss those other things as appropriate. This= WG is just about D&S.

Time is ticking away and IETF107 in Vancouver is now only= 10 weeks away. We could spend 10 more weeks talking past one another, or= we could settle on what needs to be done, hopefully get the ADs/IESG to = buy in, and get down to work.

-Glenn Deen

[1] https://mailarchive.= ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw
[2] https://mailarchive.ietf.org/arch/ms= g/add/XudG5id0wwdRndR5za4G9ZbCo_w

--=_MailMate_BBFCF0BA-2895-4045-AAC4-F188B87A43E4_=-- From nobody Thu Jan 9 09:05:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275C12001A for ; Thu, 9 Jan 2020 09:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 0gVVZVUv22to for ; Thu, 9 Jan 2020 09:05:22 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 88FD3120019 for ; Thu, 9 Jan 2020 09:05:22 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id x7so3484440pgl.11 for ; Thu, 09 Jan 2020 09:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=utDAQ5OTo1FZcgh5GyZZTi6dNOi03y1n2TQsqCnLwwo=; b=h0PRX+783Vaty05xe2OQVOrKvJYhKKMu5gGGP7OS9oZ7f0G4nAxIRfR6ryWj4v47pj 6GrwhJb+hHtjA4Ez3/I6HpYS0IPcYCc9RuxuqnNwMWgTIg+10a17pSHkDyqwoFdUikt9 ivajNbVlt+VhZwyO1GE1MbB9uNvP+9h7KjPfHcPm6Whra4Sh66D6qr9zfXLFXMYN6aY4 FPA36PrDxkoGmROikvJQnMH5e/UUX6cMstJua2x0LuDMcKXgNg3xipbLbDle/PqJzbBs tMsFkARtQ7fMgelgYL1lRcRrmxM5KvK2VPqfbhllrgxiwVdD99B8wyUPPIfuVWaDr3oY lHJw== 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=utDAQ5OTo1FZcgh5GyZZTi6dNOi03y1n2TQsqCnLwwo=; b=MimVEmUlSOW0wnILEsPCROY4wt5RjZCYjz1ehr1/6I4aV66g5N8SGhQgvnIdGrefOI WxP8TKQ4xlvRd3BOFye9lY1NIHsRPGDVkPPshwHyw3lBr+7J9+Ciq8k07o5xEWAMJjs3 Z0h2bO9ndvbJSaCE0rmPctfdWnyaHinc4ZSjQVT6VfgXEUywNGOXtmqbdvkBDTL1a2BS 5EynZrBL3MQbtzWqUjXdQ+8rRZrOBqQbV8SOccS3jTrGH48LxOqXOsEFyP945ZKTEyqL ahnbASn9TolsLUnChpy0SFhJEMJJuwXDgw64X4ed/WyDkdnItun1R8HkIM6Z6dlwDtBH lctg== X-Gm-Message-State: APjAAAV8QURT/HFFKChS6fXEtqr4+M9UbmrNM/xYUVuCudICGWX0Yr5C G8fGp+6iGSTT668EX6mu7xvQyw== X-Google-Smtp-Source: APXvYqzolDzWilqKtv1HojZEA07MKO7uXrXU4UXuRY7eGvI8cAoZ2FmcVJ5FQhQXfb54f4WDQUa1Ww== X-Received: by 2002:a62:1a97:: with SMTP id a145mr12646987pfa.244.1578589522187; Thu, 09 Jan 2020 09:05:22 -0800 (PST) Received: from [17.192.170.199] ([17.192.170.199]) by smtp.gmail.com with ESMTPSA id 12sm8959904pfn.177.2020.01.09.09.05.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 09:05:21 -0800 (PST) From: Ted Lemon Message-Id: <4EE27CEC-115C-4BAB-8369-13E507539F29@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FE0106F4-0722-45BA-B4EF-F59D1956253F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Thu, 9 Jan 2020 09:05:19 -0800 In-Reply-To: <5B682191-0638-4711-AE91-40D0626540B3@cable.comcast.com> Cc: "STARK, BARBARA H" , ADD Mailing list To: "Livingood, Jason" References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> <5B682191-0638-4711-AE91-40D0626540B3@cable.comcast.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 17:05:24 -0000 --Apple-Mail=_FE0106F4-0722-45BA-B4EF-F59D1956253F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 9, 2020, at 8:44 AM, Livingood, Jason = wrote: > [JL] Trust is relative, so it changes from person to person, country = to country, consumer to enterprise, etc. We will never solve this = question IMO. I think this is really up to each application to decide, = which may be based on direct user preferences/choice, something based on = the network (e.g. enterprise), as part of the philosophy of the app = (which is maybe why the user chose to use that app vs. a competing app), = or anything else. It would be more accurate to say that people mean a lot of different = things when they use the word trust. You are using the word here in = its natural english vernacular meaning: =E2=80=9Cdo I trust the resolver = to do X?=E2=80=9D And of course, there are lots of different things = you might mean for X, so what you said is true in this sense. However, trust in a security vernacular context means something very = specific: that you have chosen to trust something. It doesn=E2=80=99t = matter why you have chosen to trust it, so your observation doesn=E2=80=99= t apply here: either you=E2=80=99ve chosen to trust it or you haven=E2=80=99= t. So we can say that a thing is or is not trusted and be extremely = clear about what we mean. Secondarily, you can trust something in an arbitrary sense =E2=80=9CI = trust whatever resolver the network gives me=E2=80=9D or in a verifiable = sense =E2=80=9CI trust resolver X, which presents identity Y, which I am = able to validate.=E2=80=9D Again, we can discuss this quite clearly=E2=80=94there=E2=80=99s no need = to be concerned about what policy might be present in what context. If = we want to be able to arbitrarily trust resolvers that are not = identified, that=E2=80=99s a specific thing we can describe how to do. = If we want to be able to trust specific resolvers the identity of which = we are able to verify, that=E2=80=99s a different specific thing we can = describe how to do. I=E2=80=99m a bit frustrated that we keep going around on this = point=E2=80=94it would help if we could be clear about what we mean when = we talk about trust. The IETF really can=E2=80=99t reason about trust = in the english vernacular sense, but we can and do reason about trust in = the security vernacular sense. --Apple-Mail=_FE0106F4-0722-45BA-B4EF-F59D1956253F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 9, 2020, at 8:44 AM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
[JL] Trust is relative, so it changes from person to person, = country to country, consumer to enterprise, etc. We will never solve = this question IMO. I think this is really up to each application to = decide, which may be based on direct user preferences/choice, something = based on the network (e.g. enterprise), as part of the philosophy of the = app (which is maybe why the user chose to use that app vs. a competing = app), or anything else.

It would be more accurate to say that people mean a lot of = different things when they use the word trust.   You are using the = word here in its natural english vernacular meaning: =E2=80=9Cdo I trust = the resolver to do X?=E2=80=9D   And of course, there are lots of = different things you might mean for X, so what you said is true in this = sense.

However, = trust in a security vernacular context means something very specific: = that you have chosen to trust something.   It doesn=E2=80=99t = matter why you have chosen to trust it, so your observation doesn=E2=80=99= t apply here: either you=E2=80=99ve chosen to trust it or you haven=E2=80=99= t.   So we can say that a thing is or is not trusted and be = extremely clear about what we mean.

Secondarily, you can trust something in = an arbitrary sense =E2=80=9CI trust whatever resolver the network gives = me=E2=80=9D or in a verifiable sense =E2=80=9CI trust resolver X, which = presents identity Y, which I am able to validate.=E2=80=9D

Again, we can discuss = this quite clearly=E2=80=94there=E2=80=99s no need to be concerned about = what policy might be present in what context.   If we want to be = able to arbitrarily trust resolvers that are not identified, that=E2=80=99= s a specific thing we can describe how to do.   If we want to be = able to trust specific resolvers the identity of which we are able to = verify, that=E2=80=99s a different specific thing we can describe how to = do.

I=E2=80=99m = a bit frustrated that we keep going around on this point=E2=80=94it = would help if we could be clear about what we mean when we talk about = trust.   The IETF really can=E2=80=99t reason about trust in the = english vernacular sense, but we can and do reason about trust in the = security vernacular sense.

= --Apple-Mail=_FE0106F4-0722-45BA-B4EF-F59D1956253F-- From nobody Thu Jan 9 11:44:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198C4120047 for ; Thu, 9 Jan 2020 11:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=V8UUJ/w7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CsZPTRig Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYP4xG6BDPf4 for ; Thu, 9 Jan 2020 11:43:56 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7E212029C for ; Thu, 9 Jan 2020 11:43:56 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3CFE821F57; Thu, 9 Jan 2020 14:43:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 09 Jan 2020 14:43:53 -0500 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=fm2; bh=k W/+PkAX2xaRQXFuHaBnZmnnWfQssGMN4WNGGDHZoCk=; b=V8UUJ/w7L8aOKmKLp hHhbwOUyMBYwKRc1Pe5js+/HNZqOkcATzsXX6PJs77WzuQ4izDgePA+fAg4ogqi7 Tzv0/H+EoB6vHf5m3DvUJkt0oRREXInUiFvfLCo1zvwZxIP+54xw9GgZrzGjAS9F ubDWQUU/iuWubwZaFawxpZws394tSnogBtm/O2Mih+JayRnFIOn1mTuR98dRlRrM m2rBI5o9YDnHcWrLGHPTbn/p98fGM8dDtavc02J/AKPibRJ0FSD6fKjc6pmG/XjY SyolKQe4tCj44xjU0SVOVrhR0SKheX7NYoNbc6hvokdTRf9pAsYPUqWNB98j9NxZ IxQyw== 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=kW/+PkAX2xaRQXFuHaBnZmnnWfQssGMN4WNGGDHZo Ck=; b=CsZPTRigUZ8u07fhxNEBgx/F+IUVkULzOmXqR0Ok01CE9xkRaUuu9EL9/ FV12PgtHy/kQv0VK7FxFwrzwYYcNAeF0OZt7iiinn2FzLB6fLV3ISjCl3yhVK53i z0l42vJOJQLOzCPnHMpFZzLIiw8nn9wIzom3WnLdVxIgYkzQXpnBMX7VNLCdSWAb o5yG0OhT6aoSac5jYxjDmY9cXGbISoJ21hEQiVIz30TEM/extb+mHNRw5fqdqybs ewzM7cTuHcpaeAQI5Fww6fj5x95CQ3iiaoYDOq67vAGdyhGiLVtxW/yX7aDHWB1V MltpjwGdwJ/NoT69WWMSXZbHzpzbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeiuddgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgpddutddrihhnnecukfhppedujeefrdefkedruddujedrjedt necurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id EE68880065; Thu, 9 Jan 2020 14:43:51 -0500 (EST) 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, 9 Jan 2020 14:43:50 -0500 Cc: Stephen Farrell , Ben Schwartz , ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> To: =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 19:43:59 -0000 +1 I suspect a rev of the charter Tommy posted in December [1] to reflect = comments in that thread would be close enough to start the = community-wide feedback step of the chartering process, given the = support expressed for it thus far. Alissa [1] = https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w=20 > On Jan 6, 2020, at 8:53 AM, Mirja K=C3=BChlewind (IETF) = wrote: >=20 > Hi all, >=20 > I agree with Stephan in that I would prefer a more scoped charter. >=20 > I see a lot of interest in the ideas around the adaptive DNS work and = I think we should build a charter that targets exactly that, as proposed = by Tommy, to make sure that at least this piece of concrete work can = move forward (quickly). >=20 > Other topics/problems can go in to other existing or new working = groups. Especially topics related to documenting operational practices, = as mentioned below in the charter, we already have a working group for = and these topics should be discussed that group, nann my rly dnsops = (potentially leading to some rechartering of that group in order to make = clear that aspects related to operating and maintaining encrypted DNS = traffic and DNS servers are in scope). >=20 > Mirja >=20 >=20 >> Am 04.01.2020 um 17:20 schrieb Stephen Farrell = : >>=20 >> =EF=BB=BF >> Hiya, >>=20 >> The verbosity and lack of agreement and clarity on the list >> since this was posted has convinced me that this is not a >> viable charter. >>=20 >> That said, some (mostly negative, sorry;-) comments >> below... >>=20 >> Cheers, >> S. >>=20 >>> On 20/12/2019 15:20, Ben Schwartz wrote: >>> Hello ADD list, >>>=20 >>> Based on the feedback from the ABCD BoF at IETF 106, and with = additional >>> input from chairs and area directors from relevant working groups, = the ABCD >>> BoF chairs have drafted the following updated charter for a working = group. >>> Please review it and share your perspective. >>>=20 >>> Tommy Pauly has recently posted a charter text proposal that = considers >>> closely related issues. This is not a competition, so please avoid = =E2=80=9Cvoting=E2=80=9D >>> for one proposed text over the other. The text of any final charter = will >>> be written by the IESG. To help them judge whether a working group = should >>> be formed, and how it should be chartered, the most productive input = would >>> be to know which elements of each text you find valuable (if any), = and >>> which you would like to see changed in any final charter. >>=20 >> Tommy's proposal has the benefit of covering fewer topics. >> I think that's (fewer topics) likely a requirement if any >> progress is to be made. >>=20 >>>=20 >>> ----------------------------------- >>>=20 >>> Proposed charter text: >>>=20 >>> This working group will focus on DNS client side topics, = particularly >>> discovery and selection of resolvers. This complements existing = DNS-related >>> working groups, which are responsible for improvements to the DNS = protocol >>> itself, and for operational questions that are principally of = interest to >>> DNS server operators. >>=20 >> I like that you've tried to provide a logical functional >> basis for what to in/exclude in the WG. However, my take >> is that success/failure will be much more driven by the >> non-functional aspects (e.g. cat-herding, not biting off >> more than can be chewed) so I'm not sure this is needed, >> even if it's clever;-) >>=20 >>>=20 >>> The working group is chartered to develop an extensible protocol for = a DNS >>> client to learn detailed information about a resolver, based on >>> draft-ietf-dnsop-resolver-information, which will be transferred = from >>> dnsop. >>=20 >> Using that to discover that a recursive offers DoT/DoH >> seems to provide, at best, opportunistic security. But >> I like opportunistic security approaches, where they're >> useful, and it could be useful here, in some networks. >> In other networks and for some applications, the OS >> approach will provide no substantive benefit. >>=20 >> For opportunistic security to be useful also needs at >> least a story/plan for how to get to something better. So >> I think there's a major missing part here about >> re-visited networks. (Even if aspects of that are >> implementation-specific, the story is needed before we >> know the opportunistic staging post is useful.) >>=20 >> I think a wg that doesn't start out with an agreed >> understanding as to whether or not discovery being >> opportunistic is ok or not will fail. There may even >> be a need to catalog the various possible setups and how >> discovery plays out in each in order to make progress. >> (Recent list discussion with unqualified uses of the >> term "trust" along with ambiguous pronouns seems to >> indicate that may be needed.) >>=20 >> Even with all that, I'm not clear what'd motivate an >> application (whether a browser or something else) to want >> to do this, though I can see this possibly being useful >> for a system or OS stub. I could also see some applications >> using this as a way to be seen to be "doing something." All >> that said, the "useful" here doesn't seem like a huge win >> really in many networks. (IOW, if someone thinks defining >> this will stop applications using their own choices of DoH >> server, my guess is that that's wishful thinking.) >>=20 >> I don't understand the information leakage aspects of this, if a >> non-updated recursive forwards the queries upward, nor >> potential attacks (on stubs, launched by/via recursives) >> this might enable. (E.g. does the nxdomain for the first >> a.b.c.10.in-addr.arpa mean no other e.f.g.10.in-addr.arpa >> will be forwarded for the TTL?) >>=20 >> I'm not convinced this putative wg is the right place to >> develop an extensible protocol like this - dnsop seems much >> better suited really, so I'd argue to leave that draft >> in dnsop. >>=20 >>> Relying on this new protocol where appropriate, the working group >>> should produce standards-track, informational, or experimental = documents >>> that provide the following items, using the drafts in brackets as = input >>> (with no obligation to adopt them): >>> * methods for a recursive resolver to advertise support for an = alternative >>> transport protocol [draft-sah-resinfo-doh], >>=20 >> The security considerations of that seem to me to make it >> either pointless (already doing DoT/DoH) or impossible >> (DNSSEC for 10.in-addr.arpa). >>=20 >>> * methods for a recursive resolver to indicate that it will = sometimes >>> return DNS results that are different from the global DNS >>> [draft-grover-add-policy-detection], >>=20 >> That bit seems ok, though canaries are fragile of course. >> It's not clear to me that needs to be in the same WG as >> the recursive discovery bits, but it could be. >>=20 >> I don't get why both TBD.arpa and .arpa would >> need to be supported by recursive developers. ISTM one >> kind of oddball qname for this stuff ought suffice for all >> of the things envisaged in these drafts. >>=20 >>> * methods for improving user privacy by avoiding DNS queries that = leak >>> information or directing them to a server that will have this = information >>> anyway [draft-pauly-dprive-adaptive-dns-privacy], and >>=20 >> I think that draft by itself (and what it implies) is >> already the meat for an ambitious WG. >>=20 >>> * a format for describing the client=E2=80=99s DNS configuration, = suitable for >>> diagnostics and debugging. >>=20 >> I'm not clear why this is needed. >>=20 >> Attempting all of the above is IMO way too ambitious given >> the divergent interests and trust models visible in folks >> postings to this list over the last 8 months. >>=20 >>>=20 >>> Where possible, any mechanisms that specify exchange of information = between >>> clients and resolvers should provide the security properties = expected of >>> IETF protocols, e.g., confidentiality protection, integrity = protection, and >>> authentication with strong work factor. Each specification must = clearly >>> indicate under what circumstances and assumptions these properties = are or >>> are not provided. >>=20 >> I'm not sure why including that boilerplate-like text is >> a good idea. >>=20 >>> This working group will coordinate and share WGLC announcements with = the >>> following working groups: dnsop, capport, dprive, dhc, and homenet. = The >>> working group will also coordinate with the Security Area, and will = be >>> assigned a security advisor. >>=20 >> Assigned security advisors aren't that useful I think. The >> person concerned is either interested or not, if they are >> they'll not be shy. If they're not, they'll not be useful. >>=20 >>>=20 >>> P.S. One note regarding this proposal: the chairs of the doh working = group >>> expect that doh would be closed if a new working group were = chartered in >>> this manner or similar. >>>=20 >>>=20 >> <0x5AB2FAF17B172BEA.asc> >> --=20 >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Thu Jan 9 12:19:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C21120800 for ; Thu, 9 Jan 2020 12:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 lODcvc2vH6Jn for ; Thu, 9 Jan 2020 12:19:24 -0800 (PST) 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 50F9D120047 for ; Thu, 9 Jan 2020 12:19:24 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id i23so3900463pfo.2 for ; Thu, 09 Jan 2020 12:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y7gtyiAjW5xWbJqceEAR5cxgQmYdBe5A0cT4ursdQjk=; b=HXHRDdvjjn4p1Eao9wz4YnE8pf7OjJUIq00bqvIIailtSFkhOiuntU+I8y8UJ2bT4X J2kzK3Kpgk+u3thW1RIn5vDWC1Zd9Gxp8wLaAKPS5GBr/QQkLA5OJhu7vXjE7ni6ItpE wlqw0chGWm/1/WMBkwivqzaFhRZcWLygPqbBEoVXMldizP1NXyy8Cg8fJ6SL97nbx/1G DAVP8VjSAhkN/lJMt2Ejm1TL7/8r1DbC9/KggPvrWIN/PtGZGPiKLioqeK6w/4kRkwI5 59vrUF91I4cB64+Y4BgcMK3OAUJubeI5Z9HtWpG7e+2vvKCt6M5T2aZ6TnM4SO7Y43C5 f+mQ== 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=Y7gtyiAjW5xWbJqceEAR5cxgQmYdBe5A0cT4ursdQjk=; b=IDhpnBWtS7Z1/hkHEFSZQoUuu9wHSUjgnFsTlbsWaXNBtVwdHvD2XqIQKjjkxMLmaL 7e0eMOukVqa3wa8X0UkuOAIbSb4cZ5VM8y5co/qvr2nBy4Hqj+PowyUGJoo3j2mmPEjD ouelRtsQ5tGLGdcW7Cf2EyVQp5lJWlVsnPWcWMKCx0YGqmNXZLOXkBshZrAZTQlOI5uV aeugOt+HjLhu0rPE1S90qBY11nJZTL12tUKf/kneSxkAQW7zMYjM6mF+7ZmmOatow1yS Iqp+5MVLs31PjyjjlS4UgCnMH4bD+lAc/fqLUMSKCAcd4B3uQicwUGcyoHWkdW/J+T8q 9ALA== X-Gm-Message-State: APjAAAUe8pJTqzm5VteiDYAt0aeRm75y5ro47iZMaK2vEIq5QVFV5En0 5zW8QLJUPLqdZQq413redxxsqLlqeZc= X-Google-Smtp-Source: APXvYqwdGngGJN9icJwuycJd/EmwCMBdD5gDYO5zo2jzYiqmRqFRE2f8dfONOsceTOPsSdKNOy3qiw== X-Received: by 2002:a63:4006:: with SMTP id n6mr13123480pga.139.1578601162947; Thu, 09 Jan 2020 12:19:22 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.170.45]) by smtp.gmail.com with ESMTPSA id s131sm9859295pfs.135.2020.01.09.12.18.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 12:19:04 -0800 (PST) From: Ted Lemon Message-Id: <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A28FE948-7CDE-49C4-9483-DE5FDB9C3470" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Thu, 9 Jan 2020 12:18:47 -0800 In-Reply-To: Cc: =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= , Ben Schwartz , ADD Mailing list , Stephen Farrell To: Alissa Cooper References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:19:26 -0000 --Apple-Mail=_A28FE948-7CDE-49C4-9483-DE5FDB9C3470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 9, 2020, at 11:43 AM, Alissa Cooper wrote: > I suspect a rev of the charter Tommy posted in December [1] to reflect = comments in that thread would be close enough to start the = community-wide feedback step of the chartering process, given the = support expressed for it thus far. >=20 > [1] = https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w = I agree with this in a general sense, although figuring out how to = update Tommy=E2=80=99s proposal based on the subsequent discussion might = be challenging because there=E2=80=99s been so much of it. I do not think Glenn Dean=E2=80=99s proposal is a good place to start. = It would however be useful for Glenn to say what he would want changed = in Tommy=E2=80=99s version of the charter. The problem with Glenn=E2=80=99s proposal is that it largely ignores = what has been discussed thus far, and leaves things wide open rather = than tightly scoped, which has caused problems in the past. A DHCP = option to configure DoH servers would be in-scope for Glenn=E2=80=99s = charter, for example, and could be done without any discussion about how = to establish or validate trust, which I think would be an unfortunate = outcome because there would be no point in implementing it. --Apple-Mail=_A28FE948-7CDE-49C4-9483-DE5FDB9C3470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 9, 2020, at 11:43 AM, Alissa Cooper <alissa@cooperw.in> = wrote:
I suspect a = rev of the charter Tommy posted in December [1] to reflect comments in = that thread would be close enough to start the community-wide feedback = step of the chartering process, given the support expressed for it thus = far.

[1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9= ZbCo_w

I = agree with this in a general sense, although figuring out how to update = Tommy=E2=80=99s proposal based on the subsequent discussion might be = challenging because there=E2=80=99s been so much of it.

I do not think Glenn = Dean=E2=80=99s proposal is a good place to start.  It would however = be useful for Glenn to say what he would want changed in Tommy=E2=80=99s = version of the charter.

The problem with Glenn=E2=80=99s proposal is that it largely = ignores what has been discussed thus far, and leaves things wide open = rather than tightly scoped, which has caused problems in the past. =  A DHCP option to configure DoH servers would be in-scope for = Glenn=E2=80=99s charter, for example, and could be done without any = discussion about how to establish or validate trust, which I think would = be an unfortunate outcome because there would be no point in = implementing it.

= --Apple-Mail=_A28FE948-7CDE-49C4-9483-DE5FDB9C3470-- From nobody Thu Jan 9 12:26:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8EB120803 for ; Thu, 9 Jan 2020 12:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaIpbp20SSr6 for ; Thu, 9 Jan 2020 12:26:51 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB468120801 for ; Thu, 9 Jan 2020 12:26:51 -0800 (PST) Received: from pps.filterd (m0047965.ppops.net [127.0.0.1]) by m0047965.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 009KOHu9041748 for ; Thu, 9 Jan 2020 15:26:51 -0500 Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0047965.ppops.net-00176a04. with ESMTP id 2xar83v00u-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 09 Jan 2020 15:26:51 -0500 Received: from unknown (HELO ashemwp00034.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 09 Jan 2020 12:26:50 -0800 Received: from ashemwp00012.mail.tfayd.com (100.126.24.36) by ashemwp00033.mail.tfayd.com (100.126.24.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 15:26:49 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00012.mail.tfayd.com (100.126.24.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 15:26:48 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 9 Jan 2020 15:26:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IKG33JhJyymMbx4FCAOl+VSr/Sk0rcCJkKAg0uPyCLevVxKjy67GZcIG0kvTBfIOCzvn6w3hs0s5PScbrQgKPhFLXHPTeCzKgka/fTdcyVcxeNwSm7Y6YGafD/2Oya9KPKulhoylSQcJU9e72hn9jmfFreWVKIvJq5tpcHWCO7TZjfuDOjquTmZ1D+n+6PRgeTKYD/IrU1loigGCVrTUnGMPjoaC8nSz7Q0+Ekdu9VIF+qCtzP7F7LorF7o7Be1Tl0v48awyEn/9lAO6tVzeBF9ryY3WIv1i96RfyyQbeSQ4f2VOD4VnAI5Bn16NvXhW2gLNY/nlrN9v06m0pTF42g== 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=XIskZakf0sKFQPs95KVkR0LPV1APmY+jnr9OdAWKyRI=; b=GgnyDj27+sjYXuWdkWopYPNDKcZaHOxb+xo55tS/f/5RNbL5C7Eptdb0L+Z6WMCW61q8uTcoykHAFhsEhQ+B7DEiv8lFcK6m58lLpbGA/rZIo0EYdD8tQEDeXLKpRLdGF5KMERdvLPU5wTufkGSszdG3kxbBVBlXqtgOBYpEkat6+s71UZ5r0Ii3h+Am8pFUSu9CiPOxsV+sTbZVmE9UnbN8XGMOoKVj5pBbJFStFF2raqVkeNmpB6/hc2owujifVBO+JT6TmaBNmbHX26svblelw/UTvsuHQSxohL8gINibOMRm6zFmqXfUzK2Cq8pJuQTeXa0hIYljOMVMbtkorA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XIskZakf0sKFQPs95KVkR0LPV1APmY+jnr9OdAWKyRI=; b=xSJJncu2QlfhSgNEZbmDW8dlqByDIc3av9wDieaty2uRRRouSfe4m6zW7fNGg0kwYE4W/JfeLntoag+/BEPgDQkWQp5tcGC3rv/TcgRpyG+hAOLgQwaFYy2owjnVu4TYWibp3xmCbuzB7nBjjq3ubQ7EM4QIwT7CIzI90XFK044= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB2138.namprd14.prod.outlook.com (20.176.89.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 20:26:47 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 20:26:47 +0000 From: "Deen, Glenn (NBCUniversal)" To: Mirja Kuehlewind , Vittorio Bertola CC: ADD Mailing list , Stephen Farrell , "Deen, Glenn (NBCUniversal)" Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxysdTY9pjqmcaE+ILgeg0ueHRA== Date: Thu, 9 Jan 2020 20:26:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [108.185.101.45] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a1153f86-e057-4d8f-abb7-08d795424042 x-ms-traffictypediagnostic: DM6PR14MB2138: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(376002)(136003)(366004)(189003)(199004)(76116006)(91956017)(316002)(2906002)(33656002)(6512007)(66476007)(86362001)(26005)(66946007)(2616005)(64756008)(186003)(66556008)(81166006)(54906003)(8936002)(110136005)(5660300002)(8676002)(66446008)(71200400001)(107886003)(4326008)(6486002)(478600001)(6506007)(36756003)(966005)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB2138; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8qijsHlgQT9Wbpm0U4t3qLAyTu6udoG0HSdr9xCiNrLteJpO8062Wv1sR/4jCeYoRB+pyrlwEXO1bVQcV23gx9wdPCPAdQfIfX56Ov5i7DoH8GeN67dUGqMqkvYtwlp9Qj3251bN7MZI7JsGr1wcBXP5m+Xb3LhA5EoEJLuuSPletZtqeVS0DNPWb83PJEZarCinpG5T4sGi3fVal2y7QljuGFtvXoyCo8HJtivtFgMCqeffy7crXUKhKNHj4xJnuMSl7H3bqa1T/dM5ofLv9lsIHvxBySH8y/zEHeEbbSODoR5tKfwijGgeQutCB5TxEfKEb5/B9eI/gSIRw2KUsu8aA96gsoI2KbYwRR2wtM/QIrzT0KpG27NtZqSG6XKmDWeGA+aZuVK22MINOBpZHv4FKtDAr6uBZuQEuuA82lABdSls97Ns0QaXIr5vgKA9IiDVV4xFuiEis7xdYiNikF39nI6u+6ZAJE8liqAvlQ5nQKkN5yZTBpbmZSSJwC9kYauemEGYKprIS4WU2ai6RQ== Content-Type: text/plain; charset="utf-8" Content-ID: <439A6C80692EF5469FC4A22ED1E75FC9@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a1153f86-e057-4d8f-abb7-08d795424042 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 20:26:47.4357 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GgSFTFFSAgPQWCerAqLcho5TPLSo1p9F0KCmSVQ7VgDyT12r9LDM+9co5KOR8rDuuxvPRJZqGv+qImuolrnxmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB2138 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_04:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 spamscore=0 mlxscore=0 phishscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1011 malwarescore=0 priorityscore=1501 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090167 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:26:53 -0000 DQoNCu+7v09uIDEvOC8yMCwgNToyMSBBTSwgIkFkZCBvbiBiZWhhbGYgb2YgTWlyamEgS3VlaGxl d2luZCIgPGFkZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpZXRmQGt1ZWhsZXdpbmQu bmV0PiB3cm90ZToNCg0KICAgIEhpIFZpdHRvcmlvLA0KICAgIA0KICAgIFRoZSBjaGFydGVyIHBy b3Bvc2VkIGJ5IFRvbW15IChzZWUgWzFdKSBpcyBleGFjdGx5IGZvY3VzaW5nIG9uIGRpc2NvdmVy eSBhbmQgc2VsZWN0aW9uLiBXaGF0IGFyZSB5b3UgbWlzc2luZyB0aGVyZT8NCiAgICANCiAgICBN aXJqYQ0KICAgIA0KICAgIFsxXSBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hZGQvWHVkRzVpZDB3d2RSbmRSNXphNEc5WmJD b193X187ISFQSVplZVc1d3NjeW5SUSE2VklkYS1XbTl6SGM5Y0NyQTJmNnJiMkNBN3pTQ2ZvcWEz em1lMkVWZXNNQjladnZiVlBYa2FNT2VmcktMcDVfJCANCiAgICANCldoaWxlIEkgYWdyZWUgdGhh dCBpdCBpcyBmb2N1c2VkIG9uIEQmUyBpdCBpbmNsdWRlcyB0ZXh0IGF0IHRoZSBlbmQgcHVsbGlu ZyBpbiBkcmFmdC1wYXVseS1kcml2ZS1hZGFwdGl2ZS1kbnMtcHJpdmFjeSBhcyBhIHN0YXJ0aW5n IHBvaW50LiBUaGF0IHRha2VzIGlzIGJleW9uZCBqdXN0IEQgJiBTIGFuZCBpbnRvIG1vcmUgYWR2 YW5jZWQgYmVoYXZpb3Igb2YgcmVzb2x2ZXJzIGFzIGRyYWZ0LXBhdWx5LWRyaXZlLWFkYXB0aXZl LWRucy1wcml2YWN5IGdvZXMgYmV5b25kIGp1c3QgRCZTLg0KDQpBcyBJIHNhaWQgaW4gbXkgb3Ro ZXIgbm90ZSwgSSB0aGluayBpdCdzIHRoZSBhZGRpbmcgb2YgdGhlc2Ugc3RhcnRpbmcgcG9pbnRz IHRoYXQgbWF5YmUgY2F1c2luZyBhIGxvdCBvZiB0aGUgaXNzdWVzIGNvbWluZyB0byBjbG9zdXJl LiAgIFRvbW15J3MgcHJvcG9zYWwgZG9lcyBnaXZlIHRoZSBXRyB0aGUgb3B0aW9uIGFzIGhlIHNh eXMgaXQgaXMgc3ViamVjdCB0byB0aGUgV0cncyBkZXNpZ24gY2hvaWNlcy4gIEEgY29uY2VybiBj b3VsZCBiZSBpZiB0aGUgdGV4dCBhYm91dCBpdCBiZWluZyBhbiBvcHRpb24gZGlzYXBwZWFyZWQg YW5kIGl0IGJlY2FtZSBhIHJlcXVpcmVtZW50IHRvIHRha2Ugb24gdGhlIG1hdGVyaWFsIGluIHRo YXQgZHJhZnQgdGhhdCBnb2VzIGJleW9uZCBEJlMgYW5kIGludG8gcmVzb2x2ZXIgYmVoYXZpb3Iu DQoNCi1nbGVubg0KDQo= From nobody Thu Jan 9 12:37:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90981202A0 for ; Thu, 9 Jan 2020 12:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 0AB-R7QWMiBx for ; Thu, 9 Jan 2020 12:37:28 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 F392D12011B for ; Thu, 9 Jan 2020 12:37:27 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id ay11so2987645plb.0 for ; Thu, 09 Jan 2020 12:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lJtaYgy4YQ7bvUTVmNH78kLFJcHjgl1yxWGtvl261A8=; b=Kzc8CjOjcAA1I4pyYX7v1gCKifAP4axWdWSzndtCgkk1AlM/CLQ8igSrdAsl1X0AIe bdc9MXNCF5uqK/M7OnOY+nWQ24gFZTDefxan9XoXIWF0MGeRkCi80MMlvZISP85mtvUm AqqmZ//UMJ0BjFN7Cq7ntOdMINigBtOf87uSqYzNaXRqUbZDbodpl9gI53v5NL+zTZUa G4cf5WaMNmZ9FI/ra5afY+Gz7rMc2jDKkWaHOsrog7vPpk7WHMQHijsRiwvjtLLAgh3q J0BfSQUy275ROPPf6iQ7ughxNRHrqo3AQpCVk2HG2w83JMNzTeVjfLX1/mas+Cc9bRuL 25Fg== 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=lJtaYgy4YQ7bvUTVmNH78kLFJcHjgl1yxWGtvl261A8=; b=rz/leuFUF8OZEF8q940TFOKXnZhxZ/Mfjor5VD63MvH/m1Y+4akpd+KLWGPcwpY+vc nbNm8CVk/EB0TYaNl1urpV6MC4y4VhMr1xLxqgyhS/Wu5/OGeXwDnZWNietmJveJQQGu jf8VnalVqTcL1EKcG8aL8zH2dOc1/UYP0Tl+GPWxEoC4oC6RhI7VSal8nJxwweFGJ6++ F7lpSdVaa4gpi0iyXGMGeVsJQtxc8dQnjKMUKkJZJs3PPBdb549zyHLXfSU2PO+MR1Yc Qq+IXrBL+nnu7PH+Pry7qX4NYyJcyMFaaqtDru4MKfAI9v0/LylIWv8W/OfjZ9SokS4n KR7w== X-Gm-Message-State: APjAAAU/LVrE4H/f9HtQcS3XjWis7N3YWinklX3uQmtk5plh70OJ8+VU ReR0hadDj/Ucn4wQoMCBCYCIZgk97mQ= X-Google-Smtp-Source: APXvYqyA7gVUXc30dA6h+y6kdD1I8fcVS+Z+BYGazm7M6pD0CYkQAAUXoLHceVAytAY/rl9h/QHc3w== X-Received: by 2002:a17:902:9a98:: with SMTP id w24mr13798099plp.300.1578602247436; Thu, 09 Jan 2020 12:37:27 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.170.45]) by smtp.gmail.com with ESMTPSA id o31sm8692159pgb.56.2020.01.09.12.37.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 12:37:26 -0800 (PST) From: Ted Lemon Message-Id: <1FE0B6A9-F58E-4CFB-9617-8ED5145903E5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6A50D327-2FBF-4692-9FB9-47353A073556" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Thu, 9 Jan 2020 12:37:24 -0800 In-Reply-To: Cc: Mirja Kuehlewind , Vittorio Bertola , ADD Mailing list , Stephen Farrell To: "Deen, Glenn (NBCUniversal)" References: X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:37:30 -0000 --Apple-Mail=_6A50D327-2FBF-4692-9FB9-47353A073556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 9, 2020, at 12:26 PM, Deen, Glenn (NBCUniversal) = wrote: > As I said in my other note, I think it's the adding of these starting = points that maybe causing a lot of the issues coming to closure. = Tommy's proposal does give the WG the option as he says it is subject to = the WG's design choices. A concern could be if the text about it being = an option disappeared and it became a requirement to take on the = material in that draft that goes beyond D&S and into resolver behavior. Another way to look at this is that some of us would really like to work = on that proposal of Tommy=E2=80=99s, and this could be where we do it. = We could also do it in dprive, perhaps. Some people want to work on = this, some don=E2=80=99t. But if this work were chartered, it would = definitely get worked on, which is kind of the point of charter items in = a working group=E2=80=99s charter. Separately, there is a wish to be able to publish information about = locally available private resolvers for cases where something like what = Tommy is proposing is not configured, and for devices where what Tommy = is proposing simply wouldn=E2=80=99t make sense. However, the text at the end of Tommy=E2=80=99s proposed charter is = constraining what would be an acceptable solution to this problem, not = requiring adaptive DNS as a solution to all problems. The constraint is = simply that, like other IETF protocols, whatever the WG comes up with = should document and address security and privacy concerns. A solution = that doesn=E2=80=99t do this would be out of scope for Tommy=E2=80=99s = charter, and I think that=E2=80=99s desirable. --Apple-Mail=_6A50D327-2FBF-4692-9FB9-47353A073556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 9, 2020, at 12:26 PM, Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:
As I said in my other note, I think it's the adding of these = starting points that maybe causing a lot of the issues coming to = closure.   Tommy's proposal does give the WG the option as he = says it is subject to the WG's design choices.  A concern could be = if the text about it being an option disappeared and it became a = requirement to take on the material in that draft that goes beyond = D&S and into resolver behavior.

Another way to look at this is that some of = us would really like to work on that proposal of Tommy=E2=80=99s, and = this could be where we do it.   We could also do it in dprive, = perhaps.   Some people want to work on this, some don=E2=80=99t. =  But if this work were chartered, it would definitely get worked = on, which is kind of the point of charter items in a working group=E2=80=99= s charter.

Separately, there is a wish to be able to publish information = about locally available private resolvers for cases where something like = what Tommy is proposing is not configured, and for devices where what = Tommy is proposing simply wouldn=E2=80=99t make sense.

However, the text at the = end of Tommy=E2=80=99s proposed charter is constraining what would be an = acceptable solution to this problem, not requiring adaptive DNS as a = solution to all problems.  The constraint is simply that, like = other IETF protocols, whatever the WG comes up with should document and = address security and privacy concerns.   A solution that doesn=E2=80=99= t do this would be out of scope for Tommy=E2=80=99s charter, and I think = that=E2=80=99s desirable.

= --Apple-Mail=_6A50D327-2FBF-4692-9FB9-47353A073556-- From nobody Thu Jan 9 12:38:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB66120047 for ; Thu, 9 Jan 2020 12:38:00 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RQDtJpWK4CJa for ; Thu, 9 Jan 2020 12:37:58 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 7BE2D120288 for ; Thu, 9 Jan 2020 12:37:58 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 009Kb7uW034011; Thu, 9 Jan 2020 12:37:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=8ljlpZTAGQhbHLMr0c/yYQJ7A2jKb/WVATeP3oXeYJc=; b=oFyXj25sg7ECrNJ2TkE/J0DuU8TAg4SBqUgnSoMFiMSt6xjKWlDnGZw3SxmtmZKMnWjO EzUlwz9dLEg7TjNPfSKSSg43BMkgxQ3eKI0nLqCZlbsoCl8ltg/713aoxS+e5YZioAUs 6HLtWlYTkji4kQLbcCBTeyrXnj6uU31YZiUlql1EyKq3bwoKISpom48vP3B8EnuTE9Sj BC/DT15Quzp1S5o28Hr64/hE/nbhCWd4G6VBx1HOiAEAejICw5Rm7RpyEHopaDna6ueS UBumvaRIjw0lrz0UsF7/0mw0+48oY8hmyoulmGaNJEtrDqsKOSOqeykrhLt3d/GCBHHp 1w== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2xe5h2q9pt-14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 09 Jan 2020 12:37:53 -0800 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q3U00KQ0XB3P350@ma1-mtap-s01.corp.apple.com>; Thu, 09 Jan 2020 12:37:52 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q3U00000W9HWA00@nwk-mmpp-sz09.apple.com>; Thu, 09 Jan 2020 12:37:51 -0800 (PST) X-Va-A: X-Va-T-CD: X-Va-E-CD: X-Va-R-CD: X-Va-CD: 0 X-Va-ID: 5a97bb4e-e9c8-4c22-bdad-09a810324bd3 X-V-A: X-V-T-CD: 99516d15e712de0c95280005c0268c18 X-V-E-CD: 3b057decf2847b632b89ebbbdae31b6a X-V-R-CD: f72447924befeb80c3b03e1610ab2790 X-V-CD: 0 X-V-ID: 4cfffd58-3ffc-48f6-85ce-cb84df64777d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-09_04:,, signatures=0 Received: from [17.192.171.152] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q3U00FTDXB2NC10@nwk-mmpp-sz09.apple.com>; Thu, 09 Jan 2020 12:37:50 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: Date: Thu, 09 Jan 2020 12:37:47 -0800 Cc: Mirja Kuehlewind , Vittorio Bertola , ADD Mailing list , Stephen Farrell Content-transfer-encoding: quoted-printable Message-id: References: To: "Deen, Glenn (NBCUniversal)" X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-09_04:, , signatures=0 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:38:01 -0000 > On Jan 9, 2020, at 12:26 PM, Deen, Glenn (NBCUniversal) = wrote: >=20 >=20 >=20 > =EF=BB=BFOn 1/8/20, 5:21 AM, "Add on behalf of Mirja Kuehlewind" = wrote: >=20 > Hi Vittorio, >=20 > The charter proposed by Tommy (see [1]) is exactly focusing on = discovery and selection. What are you missing there? >=20 > Mirja >=20 > [1] = https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/add/XudG= 5id0wwdRndR5za4G9ZbCo_w__;!!PIZeeW5wscynRQ!6VIda-Wm9zHc9cCrA2f6rb2CA7zSCfo= qa3zme2EVesMB9ZvvbVPXkaMOefrKLp5_$=20 >=20 > While I agree that it is focused on D&S it includes text at the end = pulling in draft-pauly-drive-adaptive-dns-privacy as a starting point. = That takes is beyond just D & S and into more advanced behavior of = resolvers as draft-pauly-drive-adaptive-dns-privacy goes beyond just = D&S. I'm very happy to remove this line=E2=80=94that was mainly there to = respond to people who had asked what a charter would look like that was = based on this draft. >=20 > As I said in my other note, I think it's the adding of these starting = points that maybe causing a lot of the issues coming to closure. = Tommy's proposal does give the WG the option as he says it is subject to = the WG's design choices. A concern could be if the text about it being = an option disappeared and it became a requirement to take on the = material in that draft that goes beyond D&S and into resolver behavior. I think if we can agree on the set of deliverables and work areas, we = can forego specifying any particular draft. That certainly can and = should be the work of the WG to decide. Apart from that starting place, what other changes would be appropriate? Best, Tommy >=20 > -glenn >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Thu Jan 9 12:43:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1F312013B for ; Thu, 9 Jan 2020 12:43:32 -0800 (PST) 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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 EI0j83UHXV3C for ; Thu, 9 Jan 2020 12:43:29 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 9EC3B120047 for ; Thu, 9 Jan 2020 12:43:29 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id t8so6833500iln.4 for ; Thu, 09 Jan 2020 12:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uyvan+xr0bCFsV3rlaa1tF/wRnGabUPy1rmKNj5x5I8=; b=jPw6TCk3GFII1fllilpwxnvbojojCGnnZWUNFZ8p1fiVHgFxuAs+/BszRKbVhOgDvh pISd882wCCKYhMIuKDxUOrEOsOzukZN3U81fWo2PDIM2TqgKC6PzpFiAFFU6pS9eJK7j Rdmfjbqm8FCiQP35M9x2UXBeN9qmDGGbUkUGYjC92U/m6OY2QqS4VmtDYL+18bBmlmqz jtEIbo5io7o+yxJXlmamYKlySuLUp72XVrs2tiOFXi+4cybgPsuhAhcRZm0N9cFSoyn8 uY03zxV3vUtF1H1u5CKHQOS5/eyuS7mDvLTs6XZrxUFTNVZ8YmWyEDj5tSJZxb/0Dp0A RWmQ== 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=uyvan+xr0bCFsV3rlaa1tF/wRnGabUPy1rmKNj5x5I8=; b=V9lhrsBYl1pK2C8Vv6dBPShcDMEjNgBRaZRADdD58qJP/TGyFTBZaaaNAxW8dQtNP2 JaR+llOAwfUvoV02c5C6PIjc/BGfFMOr2s+al0pSNuBT+x6iju73J5ciDIqhGsb1cfEB l5L4SZujfEULTkl1FMSatvmqwkUu8qUpBtkZtjToepAUp0X24+VRiOYEmUdYhLa8xNej K1FMSu5DkGp9O5A/hsvKsuAExfzrKZ9rPiHTluxmRutNlyJFBsPKT1Dh3fmNHzN1rjhX PMxVfEBlc/mDxEJfbX4ZbRZGzhYeAUHDL7BKkhs+9Ap7uSCbVeElE7aMNcCtUXsAVlg9 P2gw== X-Gm-Message-State: APjAAAVV8eV7N/paKEnI8XQyBfQJTMq/bmY3VuKcrkKovpR20wDMdeKx uFSg3fk1MRxRqCNqb830P8w37XI+QbrOPAHE4/0= X-Google-Smtp-Source: APXvYqyRRIp22l7eBh8q/zEjR9z/R9Vpc5hXaqyTwGINMJgAztj1hPYNjkDIUh+lQze9fykZwLNbMrUAFyk3pjlI/BI= X-Received: by 2002:a92:1553:: with SMTP id v80mr10770482ilk.49.1578602608798; Thu, 09 Jan 2020 12:43:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Thu, 9 Jan 2020 12:43:17 -0800 Message-ID: To: Tommy Pauly Cc: "Deen, Glenn (NBCUniversal)" , Vittorio Bertola , ADD Mailing list , Mirja Kuehlewind , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000bd3095059bbb0f8c" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 20:43:32 -0000 --000000000000bd3095059bbb0f8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 12:38 PM Tommy Pauly wrote: > > > > On Jan 9, 2020, at 12:26 PM, Deen, Glenn (NBCUniversal) < > Glenn.Deen@nbcuni.com> wrote: > > > > > > > > =EF=BB=BFOn 1/8/20, 5:21 AM, "Add on behalf of Mirja Kuehlewind" < > add-bounces@ietf.org on behalf of ietf@kuehlewind.net> wrote: > > > > Hi Vittorio, > > > > The charter proposed by Tommy (see [1]) is exactly focusing on > discovery and selection. What are you missing there? > > > > Mirja > > > > [1] > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/add/Xud= G5id0wwdRndR5za4G9ZbCo_w__;!!PIZeeW5wscynRQ!6VIda-Wm9zHc9cCrA2f6rb2CA7zSCfo= qa3zme2EVesMB9ZvvbVPXkaMOefrKLp5_$ > > > > While I agree that it is focused on D&S it includes text at the end > pulling in draft-pauly-drive-adaptive-dns-privacy as a starting point. Th= at > takes is beyond just D & S and into more advanced behavior of resolvers a= s > draft-pauly-drive-adaptive-dns-privacy goes beyond just D&S. > > I'm very happy to remove this line=E2=80=94that was mainly there to respo= nd to > people who had asked what a charter would look like that was based on thi= s > draft. > > > > > As I said in my other note, I think it's the adding of these starting > points that maybe causing a lot of the issues coming to closure. Tommy'= s > proposal does give the WG the option as he says it is subject to the WG's > design choices. A concern could be if the text about it being an option > disappeared and it became a requirement to take on the material in that > draft that goes beyond D&S and into resolver behavior. > > I think if we can agree on the set of deliverables and work areas, we can > forego specifying any particular draft. That certainly can and should be > the work of the WG to decide. > > Apart from that starting place, what other changes would be appropriate? > I'm not sure what Glenn means by "resolver behavior". Does that mean client behavior? I looked at the draft again and didn't find any requirements on servers that would be incompatible with existing implementations, though of course there are some new capabilities around discovery and selection. I'd work on the Adaptive DNS draft, but if people are allergic to adopting it and iterating, perhaps a bulleted list of the problems it aims to solve would do. thanks, Rob --000000000000bd3095059bbb0f8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 12:38 PM Tommy= Pauly <tpauly=3D40apple.c= om@dmarc.ietf.org> wrote:


> On Jan 9, 2020, at 12:26 PM, Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com&= gt; wrote:
>
>
>
> =EF=BB=BFOn 1/8/20, 5:21 AM, "Add on behalf of Mirja Kuehlewind&q= uot; <add-boun= ces@ietf.org on behalf of ietf@kuehlewind.net> wrote:
>
>=C2=A0 =C2=A0 Hi Vittorio,
>
>=C2=A0 =C2=A0 The charter proposed by Tommy (see [1]) is exactly focusi= ng on discovery and selection. What are you missing there?
>
>=C2=A0 =C2=A0 Mirja
>
>=C2=A0 =C2=A0 [1] https://urldefense.com/v3/__https://mailarchiv= e.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w__;!!PIZeeW5wscynRQ!6VId= a-Wm9zHc9cCrA2f6rb2CA7zSCfoqa3zme2EVesMB9ZvvbVPXkaMOefrKLp5_$
>
> While I agree that it is focused on D&S it includes text at the en= d pulling in draft-pauly-drive-adaptive-dns-privacy as a starting point. Th= at takes is beyond just D & S and into more advanced behavior of resolv= ers as draft-pauly-drive-adaptive-dns-privacy goes beyond just D&S.

I'm very happy to remove this line=E2=80=94that was mainly there to res= pond to people who had asked what a charter would look like that was based = on this draft.

>
> As I said in my other note, I think it's the adding of these start= ing points that maybe causing a lot of the issues coming to closure.=C2=A0 = =C2=A0Tommy's proposal does give the WG the option as he says it is sub= ject to the WG's design choices.=C2=A0 A concern could be if the text a= bout it being an option disappeared and it became a requirement to take on = the material in that draft that goes beyond D&S and into resolver behav= ior.

I think if we can agree on the set of deliverables and work areas, we can f= orego specifying any particular draft. That certainly can and should be the= work of the WG to decide.

Apart from that starting place, what other changes would be appropriate?

I'm not sure what Glenn means by &quo= t;resolver behavior". Does that mean client behavior? I looked at the = draft again and didn't find any requirements on servers that would be i= ncompatible with existing implementations, though of course there are some = new capabilities around discovery and selection.

I= 'd work on the Adaptive DNS draft, but if people are allergic to adopti= ng it and iterating, perhaps a bulleted list of the problems it aims to sol= ve would do.

thanks,
Rob

<= /div>
--000000000000bd3095059bbb0f8c-- From nobody Thu Jan 9 13:33:15 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05E12080F for ; Thu, 9 Jan 2020 13:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 ZcmSsGq8B9DW for ; Thu, 9 Jan 2020 13:33:12 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E12A112081D for ; Thu, 9 Jan 2020 13:33:11 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 009LQN8D036379; Thu, 9 Jan 2020 16:33:10 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2xds936u8h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 16:33:10 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 009LX9S1005694; Thu, 9 Jan 2020 16:33:09 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 009LX4XR005459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jan 2020 16:33:04 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 1DA06400AE35; Thu, 9 Jan 2020 21:33:04 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30487.vci.att.com (Service) with ESMTPS id 061C8400AE34; Thu, 9 Jan 2020 21:33:04 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.148]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0468.000; Thu, 9 Jan 2020 16:33:03 -0500 From: "STARK, BARBARA H" To: "'Ted Lemon'" CC: "'ADD Mailing list'" Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVt0kQma20/9Ym9keiujEJ3hlN+afbGwiAgAL7pICABRjOAIAACcSA//+uOxA= Date: Thu, 9 Jan 2020 21:33:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> In-Reply-To: <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.81.68] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6115373CD75GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_05:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 clxscore=1015 malwarescore=0 spamscore=0 bulkscore=0 mlxscore=0 impostorscore=0 adultscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090177 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 21:33:14 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6115373CD75GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRlZCBMZW1vbg0KDQpPbiBKYW4gOSwgMjAyMCwgYXQgMTE6NDMgQU0sIEFsaXNz YSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5pbj4+IHdy b3RlOg0KSSBzdXNwZWN0IGEgcmV2IG9mIHRoZSBjaGFydGVyIFRvbW15IHBvc3RlZCBpbiBEZWNl bWJlciBbMV0gdG8gcmVmbGVjdCBjb21tZW50cyBpbiB0aGF0IHRocmVhZCB3b3VsZCBiZSBjbG9z ZSBlbm91Z2ggdG8gc3RhcnQgdGhlIGNvbW11bml0eS13aWRlIGZlZWRiYWNrIHN0ZXAgb2YgdGhl IGNoYXJ0ZXJpbmcgcHJvY2VzcywgZ2l2ZW4gdGhlIHN1cHBvcnQgZXhwcmVzc2VkIGZvciBpdCB0 aHVzIGZhci4NClsxXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FkZC9Y dWRHNWlkMHd3ZFJuZFI1emE0RzlaYkNvX3c8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19hZGRf WHVkRzVpZDB3d2RSbmRSNXphNEc5WmJDby01RncmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNR aWN2aklnJnI9TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPVBiUXIySmJheHR6T1diVThPUy1yWlQw UjIzelk3ODRiNVE4R21JMTl2bmsmcz1jTHd3aEM0dDlWMm1XMHlabENlcDRIOWI2eURMYXFGblQ2 bEJ1R0x1dW9ZJmU9Pg0KDQpJIGFncmVlIHdpdGggdGhpcyBpbiBhIGdlbmVyYWwgc2Vuc2UsIGFs dGhvdWdoIGZpZ3VyaW5nIG91dCBob3cgdG8gdXBkYXRlIFRvbW154oCZcyBwcm9wb3NhbCBiYXNl ZCBvbiB0aGUgc3Vic2VxdWVudCBkaXNjdXNzaW9uIG1pZ2h0IGJlIGNoYWxsZW5naW5nIGJlY2F1 c2UgdGhlcmXigJlzIGJlZW4gc28gbXVjaCBvZiBpdC4NCg0KSSBkbyBub3QgdGhpbmsgR2xlbm4g RGVhbuKAmXMgcHJvcG9zYWwgaXMgYSBnb29kIHBsYWNlIHRvIHN0YXJ0LiAgSXQgd291bGQgaG93 ZXZlciBiZSB1c2VmdWwgZm9yIEdsZW5uIHRvIHNheSB3aGF0IGhlIHdvdWxkIHdhbnQgY2hhbmdl ZCBpbiBUb21teeKAmXMgdmVyc2lvbiBvZiB0aGUgY2hhcnRlci4NCg0KVGhlIHByb2JsZW0gd2l0 aCBHbGVubuKAmXMgcHJvcG9zYWwgaXMgdGhhdCBpdCBsYXJnZWx5IGlnbm9yZXMgd2hhdCBoYXMg YmVlbiBkaXNjdXNzZWQgdGh1cyBmYXIsIGFuZCBsZWF2ZXMgdGhpbmdzIHdpZGUgb3BlbiByYXRo ZXIgdGhhbiB0aWdodGx5IHNjb3BlZCwgd2hpY2ggaGFzIGNhdXNlZCBwcm9ibGVtcyBpbiB0aGUg cGFzdC4gIEEgREhDUCBvcHRpb24gdG8gY29uZmlndXJlIERvSCBzZXJ2ZXJzIHdvdWxkIGJlIGlu LXNjb3BlIGZvciBHbGVubuKAmXMgY2hhcnRlciwgZm9yIGV4YW1wbGUsIGFuZCBjb3VsZCBiZSBk b25lIHdpdGhvdXQgYW55IGRpc2N1c3Npb24gYWJvdXQgaG93IHRvIGVzdGFibGlzaCBvciB2YWxp ZGF0ZSB0cnVzdCwgd2hpY2ggSSB0aGluayB3b3VsZCBiZSBhbiB1bmZvcnR1bmF0ZSBvdXRjb21l IGJlY2F1c2UgdGhlcmUgd291bGQgYmUgbm8gcG9pbnQgaW4gaW1wbGVtZW50aW5nIGl0Lg0KDQo8 YmhzPiBUaGVyZSB3b3VsZCB0b3RhbGx5IGJlIGEgcG9pbnQgaW4gaW1wbGVtZW50aW5nIGl0LiBU aGVyZSBhcmUgbWFueSB1c2FnZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIGFkbWluaXN0cmF0b3Igb3Ig dXNlciBvZiB0aGUgZGV2aWNlIHRydXN0cyAob3IgY2FuIGRldGVybWluZSB3aGV0aGVyIHRoZXkg dHJ1c3QpIGEgbmV0d29yay4gSnVzdCBiZWNhdXNlIERIQ1AgaXNu4oCZdCB0aGUgcmlnaHQgc29s dXRpb24gZm9yIGFsbCBzY2VuYXJpb3MsIGRvZXNu4oCZdCBtZWFuIGl0IGlzbuKAmXQgdGhlIHJp Z2h0IHNvbHV0aW9uIGZvciBzb21lIChvciBldmVuIG1hbnkpIHNjZW5hcmlvcy4gSWYgYSB1c2Vy IGNhbiBiZSBhc2tlZCB3aGV0aGVyIG9yIG5vdCB0aGUgbmV0d29yayBpcyBwdWJsaWMgb3IgcHJp dmF0ZSwgb3IgdGhlIGFkbWluaXN0cmF0b3IgY2FuIGluc3RhbGwgc29mdHdhcmUgdGhhdCBjYW4g ZGV0ZXJtaW5lIGlmIHRoZSBkZXZpY2UgaXMgb24gYSB0cnVzdGVkIG5ldHdvcmssIHRoZW4gdGhl IGRldmljZSBjYW4gdXNlIGEgY29tYmluYXRpb24gb2YgYWRtaW4gcG9saWN5IGFuZCB1c2VyIGlu cHV0IHRvIGRlY2lkZSB3aGV0aGVyIG9yIG5vdCB0byBhc2sgZm9yIC8gdXNlIERIQ1Agb3B0aW9u cy4gSnVzdCBiZWNhdXNlIHRoZSBESENQIG9wdGlvbiBpcyBwcm92aWRlZCwgZG9lc27igJl0IG1l YW4geW91IGhhdmUgdG8gdXNlIGl0LiBJZiBhIGRldmljZSBkb2VzbuKAmXQgdXNlIGl0LCB3ZeKA mXJlIG5vIHdvcnNlIG9mZiB0aGFuIG5vdywgd2l0aCBubyBESENQIG9wdGlvbiBzcGVjaWZpZWQu IElmIHRoZSBkZXZpY2UgZG9lcyB1c2UgaXQsIHRoZW4gd2XigJl2ZSBhdCBsZWFzdCBwcm92aWRl ZCBhIHNvbHV0aW9uIGZvciB0aG9zZSB1c2FnZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIG5ldHdvcmsg aXMgdHJ1c3RlZC4gUmlnaHQgbm93LCB3ZeKAmXJlIGhvbGRpbmcg4oCcbmV0d29ya3MgdHJ1c3Rl ZCBieSB0aGUgdXNlci9hZG1pbuKAnSBob3N0YWdlIHVudGlsIHNvbWUgY29udm9sdXRlZCBzb2x1 dGlvbiBjYW4gYmUgY3JlYXRlZCB0aGF0IGFkZHMgY29tcGxleGl0eSBhbmQgY29uZnVzaW9uIGZv ciB0aGUgdXNlciBhbmQgb25seSBzZXJ2ZXMgdG8gc2hpZnQgd2hvIHRoZSB1c2VyL2FkbWluIGhh cyB0byB0cnVzdCAoYnV0IGRvZXNu4oCZdCBuZWNlc3NhcmlseSBtYWtlIHRoaW5ncyBtb3JlIHNl Y3VyZSBvciBwcml2YXRlKS4NCg0KT1RPSCwgaWYgd2UgY291bGQgZmlndXJlIHNvbWV0aGluZyBv dXQgdGhhdCBpcyBzaW1wbGUgKGVzcGVjaWFsbHkgZm9yIHRoZSB1c2VyKSBhbmQgZG9lc27igJl0 IGp1c3Qgc2hpZnQgd2hvIHRoZSB1c2VyL2FkbWluIGhhcyB0byB0cnVzdCwgdGhhdCB3b3VsZCBk ZWZpbml0ZWx5IGJlIHVzZWZ1bCB0byBleHBsb3JlLg0KQmFyYmFyYSA8L2Jocz4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6115373CD75GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IFRlZCBMZW1vbjxicj4NCjxicj4NCjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEphbiA5LCAyMDIwLCBhdCAxMTo0MyBBTSwgQWxpc3NhIENvb3BlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluIj5hbGlzc2FAY29vcGVydy5pbjwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJl Z3VsYXImcXVvdDssc2VyaWYiPkkgc3VzcGVjdCBhIHJldiBvZiB0aGUgY2hhcnRlciBUb21teSBw b3N0ZWQgaW4gRGVjZW1iZXIgWzFdIHRvIHJlZmxlY3QgY29tbWVudHMgaW4gdGhhdCB0aHJlYWQg d291bGQgYmUgY2xvc2UgZW5vdWdoIHRvIHN0YXJ0IHRoZSBjb21tdW5pdHktd2lkZSBmZWVkYmFj ayBzdGVwIG9mIHRoZSBjaGFydGVyaW5nDQogcHJvY2VzcywgZ2l2ZW4gdGhlIHN1cHBvcnQgZXhw cmVzc2VkIGZvciBpdCB0aHVzIGZhci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+ WzFdJm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuaWV0Zi5vcmdfYXJjaF9tc2dfYWRkX1h1 ZEc1aWQwd3dkUm5kUjV6YTRHOVpiQ28tNUZ3JmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hV TWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209UGJRcjJKYmF4 dHpPV2JVOE9TLXJaVDBSMjN6WTc4NGI1UThHbUkxOXZuayZhbXA7cz1jTHd3aEM0dDlWMm1XMHla bENlcDRIOWI2eURMYXFGblQ2bEJ1R0x1dW9ZJmFtcDtlPSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPmh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvYWRkL1h1ZEc1aWQwd3dkUm5kUjV6YTRHOVpiQ29fdzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBhZ3JlZSB3aXRoIHRoaXMgaW4gYSBnZW5lcmFsIHNlbnNlLCBhbHRob3VnaCBmaWd1cmluZyBv dXQgaG93IHRvIHVwZGF0ZSBUb21teeKAmXMgcHJvcG9zYWwgYmFzZWQgb24gdGhlIHN1YnNlcXVl bnQgZGlzY3Vzc2lvbiBtaWdodCBiZSBjaGFsbGVuZ2luZyBiZWNhdXNlIHRoZXJl4oCZcyBiZWVu IHNvIG11Y2ggb2YgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgZG8gbm90IHRoaW5rIEdsZW5uIERlYW7igJlzIHByb3Bvc2FsIGlzIGEg Z29vZCBwbGFjZSB0byBzdGFydC4gJm5ic3A7SXQgd291bGQgaG93ZXZlciBiZSB1c2VmdWwgZm9y IEdsZW5uIHRvIHNheSB3aGF0IGhlIHdvdWxkIHdhbnQgY2hhbmdlZCBpbiBUb21teeKAmXMgdmVy c2lvbiBvZiB0aGUgY2hhcnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gd2l0aCBHbGVubuKAmXMgcHJvcG9zYWwgaXMg dGhhdCBpdCBsYXJnZWx5IGlnbm9yZXMgd2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQgdGh1cyBmYXIs IGFuZCBsZWF2ZXMgdGhpbmdzIHdpZGUgb3BlbiByYXRoZXIgdGhhbiB0aWdodGx5IHNjb3BlZCwg d2hpY2ggaGFzIGNhdXNlZCBwcm9ibGVtcyBpbiB0aGUgcGFzdC4gJm5ic3A7QSBESENQIG9wdGlv biB0byBjb25maWd1cmUgRG9IIHNlcnZlcnMgd291bGQNCiBiZSBpbi1zY29wZSBmb3IgR2xlbm7i gJlzIGNoYXJ0ZXIsIGZvciBleGFtcGxlLCBhbmQgY291bGQgYmUgZG9uZSB3aXRob3V0IGFueSBk aXNjdXNzaW9uIGFib3V0IGhvdyB0byBlc3RhYmxpc2ggb3IgdmFsaWRhdGUgdHJ1c3QsIHdoaWNo IEkgdGhpbmsgd291bGQgYmUgYW4gdW5mb3J0dW5hdGUgb3V0Y29tZSBiZWNhdXNlIHRoZXJlIHdv dWxkIGJlIG5vIHBvaW50IGluIGltcGxlbWVudGluZyBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7YmhzJmd0OyBUaGVyZSB3b3VsZCB0b3RhbGx5 IGJlIGEgcG9pbnQgaW4gaW1wbGVtZW50aW5nIGl0LiBUaGVyZSBhcmUgbWFueSB1c2FnZSBzY2Vu YXJpb3Mgd2hlcmUgdGhlIGFkbWluaXN0cmF0b3Igb3IgdXNlciBvZiB0aGUgZGV2aWNlIHRydXN0 cyAob3IgY2FuIGRldGVybWluZSB3aGV0aGVyIHRoZXkgdHJ1c3QpIGEgbmV0d29yay4gSnVzdCBi ZWNhdXNlIERIQ1AgaXNu4oCZdCB0aGUgcmlnaHQgc29sdXRpb24gZm9yDQogYWxsIHNjZW5hcmlv cywgZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCB0aGUgcmlnaHQgc29sdXRpb24gZm9yIHNvbWUg KG9yIGV2ZW4gbWFueSkgc2NlbmFyaW9zLiBJZiBhIHVzZXIgY2FuIGJlIGFza2VkIHdoZXRoZXIg b3Igbm90IHRoZSBuZXR3b3JrIGlzIHB1YmxpYyBvciBwcml2YXRlLCBvciB0aGUgYWRtaW5pc3Ry YXRvciBjYW4gaW5zdGFsbCBzb2Z0d2FyZSB0aGF0IGNhbiBkZXRlcm1pbmUgaWYgdGhlIGRldmlj ZSBpcyBvbiBhIHRydXN0ZWQgbmV0d29yaywNCiB0aGVuIHRoZSBkZXZpY2UgY2FuIHVzZSBhIGNv bWJpbmF0aW9uIG9mIGFkbWluIHBvbGljeSBhbmQgdXNlciBpbnB1dCB0byBkZWNpZGUgd2hldGhl ciBvciBub3QgdG8gYXNrIGZvciAvIHVzZSBESENQIG9wdGlvbnMuIEp1c3QgYmVjYXVzZSB0aGUg REhDUCBvcHRpb24gaXMgcHJvdmlkZWQsIGRvZXNu4oCZdCBtZWFuIHlvdSBoYXZlIHRvIHVzZSBp dC4gSWYgYSBkZXZpY2UgZG9lc27igJl0IHVzZSBpdCwgd2XigJlyZSBubyB3b3JzZSBvZmYgdGhh biBub3csDQogd2l0aCBubyBESENQIG9wdGlvbiBzcGVjaWZpZWQuIElmIHRoZSBkZXZpY2UgZG9l cyB1c2UgaXQsIHRoZW4gd2XigJl2ZSBhdCBsZWFzdCBwcm92aWRlZCBhIHNvbHV0aW9uIGZvciB0 aG9zZSB1c2FnZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIG5ldHdvcmsgaXMgdHJ1c3RlZC4gUmlnaHQg bm93LCB3ZeKAmXJlIGhvbGRpbmcg4oCcbmV0d29ya3MgdHJ1c3RlZCBieSB0aGUgdXNlci9hZG1p buKAnSBob3N0YWdlIHVudGlsIHNvbWUgY29udm9sdXRlZCBzb2x1dGlvbiBjYW4NCiBiZSBjcmVh dGVkIHRoYXQgYWRkcyBjb21wbGV4aXR5IGFuZCBjb25mdXNpb24gZm9yIHRoZSB1c2VyIGFuZCBv bmx5IHNlcnZlcyB0byBzaGlmdCB3aG8gdGhlIHVzZXIvYWRtaW4gaGFzIHRvIHRydXN0IChidXQg ZG9lc27igJl0IG5lY2Vzc2FyaWx5IG1ha2UgdGhpbmdzIG1vcmUgc2VjdXJlIG9yIHByaXZhdGUp Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9UT0gsIGlmIHdlIGNvdWxkIGZpZ3VyZSBzb21l dGhpbmcgb3V0IHRoYXQgaXMgc2ltcGxlIChlc3BlY2lhbGx5IGZvciB0aGUgdXNlcikgYW5kIGRv ZXNu4oCZdCBqdXN0IHNoaWZ0IHdobyB0aGUgdXNlci9hZG1pbiBoYXMgdG8gdHJ1c3QsIHRoYXQg d291bGQgZGVmaW5pdGVseSBiZSB1c2VmdWwgdG8gZXhwbG9yZS4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYSAmbHQ7L2JocyZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6115373CD75GAALPA1MSGUSRBF_-- From nobody Thu Jan 9 14:02:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727F5120807 for ; Thu, 9 Jan 2020 14:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 MHAJ_ThwLDA9 for ; Thu, 9 Jan 2020 14:02:32 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 31EE512021C for ; Thu, 9 Jan 2020 14:02:32 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id 203so6354652lfa.12 for ; Thu, 09 Jan 2020 14:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6vN8NEuK2xAToWxbGypAujhbxV0y5p72+NBXcfHRzlg=; b=wYyz0UjQjzx078yLGyuqruys0mVMLN0VhvPhQ68H8sCRCc8fF2AGiZ1em81le1FlVI poyicHpKv1lVcK7Y/uUAYLq2PNcE3qbKh6yPgL8WEOKXoq9O3jQkPbDngk+Gc0BVcZYH Kc7cEhKG9gfoQ0bg+wY+E5xYc91BOaU0yFobCQ+POmJTtsQ9VZhnyVbKTu19Zjlbr7Tz Mwmgw78KGzhNNJidxrisZcRyQG2zjS8TD9ytag1Wjoqzk9fHlA91yrVw2Hc+ndP6M1UG h0TFAZX41PcT0GYoJ66eAdlQMcIxkQrZ41W88aRYDjuc/ty3hW90LLwYaV/2LQyguYMn wiKw== 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=6vN8NEuK2xAToWxbGypAujhbxV0y5p72+NBXcfHRzlg=; b=Ify09ldhNhuu/kCtrDzoGrc0+rtR0ak/L/JOnclHX3uAKLEryK+nTYt1zZihqqxBdz rYr4RAYGn0IqzBZ6znokYJSi2CIy73AS5rvNgWYEeQ5AmYR6h7WqyaxefRkojE+Sj3km xi82DzevIyNJUSYr0H5EfAdFDVouZBcbo+YX2RRhhUHx3j5g8ly6tmZHYL9Upvx+fBgO XREvTR6KyGveRO1ga1MYk+CZEgtIsoqlwURziun7toxoH0iH2rQMcgbSUgS69o8tc675 aH0VAEknO9KUekZoO2JvLt3SRPS4Jy1JIa2v+UVVIFbDtkodHixh8jH3c26ML3cxIQtt MBxw== X-Gm-Message-State: APjAAAVNhmcNJEFeCY1iZu2n6W1Njjxx7rZ7iCzYT+TLGvp4xfVueJDs bMxfxxj4yIhm01CjstXGImTQ2F8qcMmta5tdvlCjklfu3LU= X-Google-Smtp-Source: APXvYqwvnWsx1a4ruysQDASUyXcZuQzoCe+UpbPr8Aq7xLhta4/VJRajyxPjyM8YR6hphxQnuOHh6/mCqJy/ohcZ4Ec= X-Received: by 2002:ac2:4422:: with SMTP id w2mr7665662lfl.178.1578607350356; Thu, 09 Jan 2020 14:02:30 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Eric Rescorla Date: Thu, 9 Jan 2020 14:01:53 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Ted Lemon , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005bbbb0059bbc2a03" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 22:02:35 -0000 --0000000000005bbbb0059bbc2a03 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H wrote: > > > > > *From:* Ted Lemon > > On Jan 9, 2020, at 11:43 AM, Alissa Cooper wrote: > > I suspect a rev of the charter Tommy posted in December [1] to reflect > comments in that thread would be close enough to start the community-wide > feedback step of the chartering process, given the support expressed for = it > thus far. > > [1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w > > > > > I agree with this in a general sense, although figuring out how to update > Tommy=E2=80=99s proposal based on the subsequent discussion might be chal= lenging > because there=E2=80=99s been so much of it. > > > > I do not think Glenn Dean=E2=80=99s proposal is a good place to start. I= t would > however be useful for Glenn to say what he would want changed in Tommy=E2= =80=99s > version of the charter. > > > > The problem with Glenn=E2=80=99s proposal is that it largely ignores what= has been > discussed thus far, and leaves things wide open rather than tightly scope= d, > which has caused problems in the past. A DHCP option to configure DoH > servers would be in-scope for Glenn=E2=80=99s charter, for example, and c= ould be > done without any discussion about how to establish or validate trust, whi= ch > I think would be an unfortunate outcome because there would be no point i= n > implementing it. > > > > There would totally be a point in implementing it. There are many > usage scenarios where the administrator or user of the device trusts (or > can determine whether they trust) a network. Just because DHCP isn=E2=80= =99t the > right solution for all scenarios, doesn=E2=80=99t mean it isn=E2=80=99t t= he right solution > for some (or even many) scenarios. If a user can be asked whether or not > the network is public or private, or the administrator can install softwa= re > that can determine if the device is on a trusted network, then the device > can use a combination of admin policy and user input to decide whether or > not to ask for / use DHCP options. Just because the DHCP option is > provided, doesn=E2=80=99t mean you have to use it. If a device doesn=E2= =80=99t use it, > we=E2=80=99re no worse off than now, with no DHCP option specified. If th= e device > does use it, then we=E2=80=99ve at least provided a solution for those us= age > scenarios where the network is trusted. Right now, we=E2=80=99re holding = =E2=80=9Cnetworks > trusted by the user/admin=E2=80=9D hostage until some convoluted solution= can be > created that adds complexity and confusion for the user and only serves t= o > shift who the user/admin has to trust (but doesn=E2=80=99t necessarily ma= ke things > more secure or private). > Can you explain your threat model here? If the network is trusted, then what are you gaining by encrypting the DNS traffic? As I mentioned, there seem to be a few edge cases where this might have some value, but I'd like to understand what it is you have in mind. -Ekr > > OTOH, if we could figure something out that is simple (especially for the > user) and doesn=E2=80=99t just shift who the user/admin has to trust, tha= t would > definitely be useful to explore. > > Barbara > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000005bbbb0059bbc2a03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 1:33 PM STARK,= BARBARA H <bs7652@att.com> wro= te:

=C2=A0

=C2=A0

From: Ted Lemon

On Jan 9, 2020, at 11:43 AM, Alissa Cooper <alissa@cooperw.in>= wrote:

I suspect a rev of the charter Tommy posted in Dec= ember [1] to reflect comments in that thread would be close enough to start= the community-wide feedback step of the chartering process, given the support expressed for it thus far.=

[1]=C2=A0= https://mailarc= hive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w=

=C2=A0

I agree with this in a general sense, although figur= ing out how to update Tommy=E2=80=99s proposal based on the subsequent disc= ussion might be challenging because there=E2=80=99s been so much of it.<= /u>

=C2=A0

I do not think Glenn Dean=E2=80=99s proposal is a go= od place to start.=C2=A0 It would however be useful for Glenn to say what h= e would want changed in Tommy=E2=80=99s version of the charter.

=C2=A0

The problem with Glenn=E2=80=99s proposal is that it= largely ignores what has been discussed thus far, and leaves things wide o= pen rather than tightly scoped, which has caused problems in the past.=C2= =A0 A DHCP option to configure DoH servers would be in-scope for Glenn=E2=80=99s charter, for example, and could be done wi= thout any discussion about how to establish or validate trust, which I thin= k would be an unfortunate outcome because there would be no point in implem= enting it.

=C2=A0

<bhs> There would totally be a point in implem= enting it. There are many usage scenarios where the administrator or user o= f the device trusts (or can determine whether they trust) a network. Just b= ecause DHCP isn=E2=80=99t the right solution for all scenarios, doesn=E2=80=99t mean it isn=E2=80=99t the right solution fo= r some (or even many) scenarios. If a user can be asked whether or not the = network is public or private, or the administrator can install software tha= t can determine if the device is on a trusted network, then the device can use a combination of admin policy and user input to de= cide whether or not to ask for / use DHCP options. Just because the DHCP op= tion is provided, doesn=E2=80=99t mean you have to use it. If a device does= n=E2=80=99t use it, we=E2=80=99re no worse off than now, with no DHCP option specified. If the device does use it, then we=E2=80=99= ve at least provided a solution for those usage scenarios where the network= is trusted. Right now, we=E2=80=99re holding =E2=80=9Cnetworks trusted by = the user/admin=E2=80=9D hostage until some convoluted solution can be created that adds complexity and confusion for the user and only serves= to shift who the user/admin has to trust (but doesn=E2=80=99t necessarily = make things more secure or private).


Can you explai= n your threat model here? If the network is trusted, then what are you gain= ing by encrypting the DNS traffic? As I mentioned, there seem to be a few e= dge cases where this might have some value, but I'd like to understand = what it is you have in mind.

-Ekr

=C2=A0

OTOH, if we could figure something out that is simpl= e (especially for the user) and doesn=E2=80=99t just shift who the user/adm= in has to trust, that would definitely be useful to explore.

Barbara </bhs>

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000005bbbb0059bbc2a03-- From nobody Thu Jan 9 14:39:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23338120827 for ; Thu, 9 Jan 2020 14:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjq0CjPKbFMJ for ; Thu, 9 Jan 2020 14:39:50 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100072.outbound.protection.outlook.com [40.107.10.72]) (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 53424120807 for ; Thu, 9 Jan 2020 14:39:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NP3Gr8YbbUjRabUxrfNPMEGNlYGJD9lAjvtb9dgXIqGHbYb/pnaPDbHPiiFwCZ2clv69Tj3RYpROQDYGT6Cs1Fflbb80ei1zJIkXXtrDfdLwNZj+qeSzGFLBRnojPBi0V65fINQ8RIuNRNinP2JtavoMa8Dsc35QGllTswYEc8xozuYhoQXRjfkwWgbNZXYlxUikvvFQX7PM45iIxIQP8Lg08gaxHi3IAAXhhAkFQHKQ46ux3+tgRLkjOEM87JV9SRdkFTpv4UoXU/zNrfinYPHxIwl+xjHZAxTyBS6QnyRZiST0R55BHBxaCsycrSrfpVUBuqIEuo1p63AX2OVF9w== 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=lntQH0ZZ/Vqrk35AfHAV+tQNGbeyfsVKiAKZOrYYBSE=; b=ebUQv0NxuoNdzWvta6WNwhUqBB/TGvN8SVmZjKkyOsSaG6VGl69YSrahJH+6YsZU+4Dk6JJn3hAg9b004hr1bKCOjnTiWj3ci2FOHBf2q/stUeZVQqQvr4a8jiHx3T8DqHAS8lM+CWgMvmiYrlx2NCrsoYN4cZtn84KfyfoHQobOUHD+jKPnQ19V1Bcr0DhDlD2Qic+KJ0aDVn3RO2V8yG2EzWu88wwTX1elcW5z7RcFRlHEHH7YDhCdXnilM/2s7JMG8udxJeF8CBH7J+KXvtIx58+K713Ly8BfFxZ0jdrcTsLsxbV1TXEXOvpWU9DLE1ecEpSbn34l1SDW/cGzjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lntQH0ZZ/Vqrk35AfHAV+tQNGbeyfsVKiAKZOrYYBSE=; b=YHw6pkFlWYLYutCs1quxyc7SIQ6Qtpz5zbGOiOBt7C4SKs70/ig/V+WJENR0X/IC3W0OYzOeBu7aG/ZyOJwiiRqho4wqI8MlYAZLQ+FotOPpT/Az5tO3JbDWVpkODiLaGcaESse7FH/8ePbOVXpZ0pV7Ofz76paljJIHh+D6CkQ= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1102.GBRP265.PROD.OUTLOOK.COM (20.176.140.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 22:39:45 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.011; Thu, 9 Jan 2020 22:39:45 +0000 From: Andrew Campling To: "STARK, BARBARA H" , 'Ted Lemon' CC: 'ADD Mailing list' Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxziFLlI6yeKg7kavCe4wN7Y8zafi6hyg Date: Thu, 9 Jan 2020 22:39:44 +0000 Message-ID: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> 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=andrew.campling@419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9dfaca0c-199d-4200-49d3-08d79554d344 x-ms-traffictypediagnostic: LO2P265MB1102: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(366004)(136003)(396003)(346002)(376002)(189003)(199004)(44832011)(71200400001)(4326008)(52536014)(86362001)(110136005)(55016002)(2906002)(53546011)(6506007)(8936002)(186003)(9686003)(5660300002)(33656002)(66476007)(81166006)(64756008)(66446008)(76116006)(66946007)(81156014)(66556008)(7696005)(508600001)(8676002)(316002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1102; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gO0T/JFDc0FYGZsosn9JZunVEUOik6nk5/yMQjYXcnRDK4PZR/rLExknktpFRbDvoFzYLvK1+n56XSk5A01LL/+menMKW8+KM3SmeKapDn4qT9gAWgJeaJnocWH8vLzu3GRk7YziKGNqEZmTBLVbkyF3EO4BsXmpAg9M0uL96LywdWepahsRSvXnKfhAbYacEA0xvp9JkmakGbK0YxmvHjpOOqNxi8l3C/Crvg2aIQfzwEjR8jeR81DAeyyr1AYgAwVcBXT6OupybPg6r/GV3FbmJ53Ysbq83QfGdyHPCxBgSw+au9PzvBqEy+uUDxBNzNkqheWrsgIxnv/cGcld1uAYF69PWTSncfotH6X9Tc8ef/6bLDiOEdNARIz9g/jAxrUeVN1OGRY3jJuDLP424m9S/sH0dDe+BUSUPcSuzeUab/SOkFefAI5Deu0k55OgA7nEYUKuSwJchi5KICjn/Kj1Q1wp5jOKMUiDDsNdH8J2nU0dsEtI+Q4iYFlfUxwL x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB05737EAD1F099B43B31A46EAC2390LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 9dfaca0c-199d-4200-49d3-08d79554d344 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 22:39:45.0084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i+rpZFMJzpPO/Ar5QuAf7QDcFKzkE/quYVP9NmIhLgZtUoSw3AtieVXDd3g2kH7QPXh14gklfpO92vvj+zXHJ+hTHtHSio4vktwyWSRaQ1k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1102 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 22:39:54 -0000 --_000_LO2P265MB05737EAD1F099B43B31A46EAC2390LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gSmFuIDksIDIwMjAsIGF0IDIxOjMzLCBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNv bT4gd3JvdGU6DQoNCjxiaHM+IFRoZXJlIHdvdWxkIHRvdGFsbHkgYmUgYSBwb2ludCBpbiBpbXBs ZW1lbnRpbmcgaXQuIFRoZXJlIGFyZSBtYW55IHVzYWdlIHNjZW5hcmlvcyB3aGVyZSB0aGUgYWRt aW5pc3RyYXRvciBvciB1c2VyIG9mIHRoZSBkZXZpY2UgdHJ1c3RzIChvciBjYW4gZGV0ZXJtaW5l IHdoZXRoZXIgdGhleSB0cnVzdCkgYSBuZXR3b3JrLiBKdXN0IGJlY2F1c2UgREhDUCBpc27igJl0 IHRoZSByaWdodCBzb2x1dGlvbiBmb3IgYWxsIHNjZW5hcmlvcywgZG9lc27igJl0IG1lYW4gaXQg aXNu4oCZdCB0aGUgcmlnaHQgc29sdXRpb24gZm9yIHNvbWUgKG9yIGV2ZW4gbWFueSkgc2NlbmFy aW9zLiBJZiBhIHVzZXIgY2FuIGJlIGFza2VkIHdoZXRoZXIgb3Igbm90IHRoZSBuZXR3b3JrIGlz IHB1YmxpYyBvciBwcml2YXRlLCBvciB0aGUgYWRtaW5pc3RyYXRvciBjYW4gaW5zdGFsbCBzb2Z0 d2FyZSB0aGF0IGNhbiBkZXRlcm1pbmUgaWYgdGhlIGRldmljZSBpcyBvbiBhIHRydXN0ZWQgbmV0 d29yaywgdGhlbiB0aGUgZGV2aWNlIGNhbiB1c2UgYSBjb21iaW5hdGlvbiBvZiBhZG1pbiBwb2xp Y3kgYW5kIHVzZXIgaW5wdXQgdG8gZGVjaWRlIHdoZXRoZXIgb3Igbm90IHRvIGFzayBmb3IgLyB1 c2UgREhDUCBvcHRpb25zLiBKdXN0IGJlY2F1c2UgdGhlIERIQ1Agb3B0aW9uIGlzIHByb3ZpZGVk LCBkb2VzbuKAmXQgbWVhbiB5b3UgaGF2ZSB0byB1c2UgaXQuIElmIGEgZGV2aWNlIGRvZXNu4oCZ dCB1c2UgaXQsIHdl4oCZcmUgbm8gd29yc2Ugb2ZmIHRoYW4gbm93LCB3aXRoIG5vIERIQ1Agb3B0 aW9uIHNwZWNpZmllZC4gSWYgdGhlIGRldmljZSBkb2VzIHVzZSBpdCwgdGhlbiB3ZeKAmXZlIGF0 IGxlYXN0IHByb3ZpZGVkIGEgc29sdXRpb24gZm9yIHRob3NlIHVzYWdlIHNjZW5hcmlvcyB3aGVy ZSB0aGUgbmV0d29yayBpcyB0cnVzdGVkLiBSaWdodCBub3csIHdl4oCZcmUgaG9sZGluZyDigJxu ZXR3b3JrcyB0cnVzdGVkIGJ5IHRoZSB1c2VyL2FkbWlu4oCdIGhvc3RhZ2UgdW50aWwgc29tZSBj b252b2x1dGVkIHNvbHV0aW9uIGNhbiBiZSBjcmVhdGVkIHRoYXQgYWRkcyBjb21wbGV4aXR5IGFu ZCBjb25mdXNpb24gZm9yIHRoZSB1c2VyIGFuZCBvbmx5IHNlcnZlcyB0byBzaGlmdCB3aG8gdGhl IHVzZXIvYWRtaW4gaGFzIHRvIHRydXN0IChidXQgZG9lc27igJl0IG5lY2Vzc2FyaWx5IG1ha2Ug dGhpbmdzIG1vcmUgc2VjdXJlIG9yIHByaXZhdGUpLg0KDQpPVE9ILCBpZiB3ZSBjb3VsZCBmaWd1 cmUgc29tZXRoaW5nIG91dCB0aGF0IGlzIHNpbXBsZSAoZXNwZWNpYWxseSBmb3IgdGhlIHVzZXIp IGFuZCBkb2VzbuKAmXQganVzdCBzaGlmdCB3aG8gdGhlIHVzZXIvYWRtaW4gaGFzIHRvIHRydXN0 LCB0aGF0IHdvdWxkIGRlZmluaXRlbHkgYmUgdXNlZnVsIHRvIGV4cGxvcmUuDQpCYXJiYXJhIDwv YmhzPg0KDQpUaGlzIHNlZW1zIGVudGlyZWx5IHNlbnNpYmxlOiBhc3N1bWluZyB0aGF0IG5vIG5l dHdvcmsgY2FuIGV2ZXIgYmUgdHJ1c3RlZCBpcyBjbGVhcmx5IG5vdCBzZW5zaWJsZSwgYXMgaXMg cnVsaW5nIG91dCBhbiBvcHRpb24gYXQgdGhpcyBzdGFnZS4gIEl0IGNvdWxkIHNpbXBsaWZ5IG1h bnkgdXNlIGNhc2VzIHRvIGRvIHNvIGFuZCB3b3VsZCBhdm9pZCBmb3JjaW5nIHRoZSB1c2VyIHRv IHRydXN0IGFub3RoZXIgZW50aXR5IHVubmVjZXNzYXJpbHkgd2hlbiBkb2luZyBzbyBoYXMgdGhl IHBvdGVudGlhbCB0byBpbnRyb2R1Y2UgYWRkaXRpb25hbCByaXNrLg0KDQoNCkFuZHJldw0KDQo= --_000_LO2P265MB05737EAD1F099B43B31A46EAC2390LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gSmFuIDksIDIwMjAsIGF0IDIxOjMzLA0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+U1RBUkssIEJBUkJB UkEgSCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jmx0O2JocyZndDsgVGhlcmUgd291bGQgdG90YWxseSBiZSBhIHBvaW50IGluIGltcGxlbWVudGlu ZyBpdC4gVGhlcmUgYXJlIG1hbnkgdXNhZ2Ugc2NlbmFyaW9zIHdoZXJlIHRoZSBhZG1pbmlzdHJh dG9yIG9yIHVzZXIgb2YgdGhlIGRldmljZSB0cnVzdHMgKG9yIGNhbiBkZXRlcm1pbmUgd2hldGhl ciB0aGV5IHRydXN0KSBhIG5ldHdvcmsuIEp1c3QNCiBiZWNhdXNlIERIQ1AgaXNu4oCZdCB0aGUg cmlnaHQgc29sdXRpb24gZm9yIGFsbCBzY2VuYXJpb3MsIGRvZXNu4oCZdCBtZWFuIGl0IGlzbuKA mXQgdGhlIHJpZ2h0IHNvbHV0aW9uIGZvciBzb21lIChvciBldmVuIG1hbnkpIHNjZW5hcmlvcy4g SWYgYSB1c2VyIGNhbiBiZSBhc2tlZCB3aGV0aGVyIG9yIG5vdCB0aGUgbmV0d29yayBpcyBwdWJs aWMgb3IgcHJpdmF0ZSwgb3IgdGhlIGFkbWluaXN0cmF0b3IgY2FuIGluc3RhbGwgc29mdHdhcmUg dGhhdCBjYW4NCiBkZXRlcm1pbmUgaWYgdGhlIGRldmljZSBpcyBvbiBhIHRydXN0ZWQgbmV0d29y aywgdGhlbiB0aGUgZGV2aWNlIGNhbiB1c2UgYSBjb21iaW5hdGlvbiBvZiBhZG1pbiBwb2xpY3kg YW5kIHVzZXIgaW5wdXQgdG8gZGVjaWRlIHdoZXRoZXIgb3Igbm90IHRvIGFzayBmb3IgLyB1c2Ug REhDUCBvcHRpb25zLiBKdXN0IGJlY2F1c2UgdGhlIERIQ1Agb3B0aW9uIGlzIHByb3ZpZGVkLCBk b2VzbuKAmXQgbWVhbiB5b3UgaGF2ZSB0byB1c2UgaXQuIElmIGEgZGV2aWNlDQogZG9lc27igJl0 IHVzZSBpdCwgd2XigJlyZSBubyB3b3JzZSBvZmYgdGhhbiBub3csIHdpdGggbm8gREhDUCBvcHRp b24gc3BlY2lmaWVkLiBJZiB0aGUgZGV2aWNlIGRvZXMgdXNlIGl0LCB0aGVuIHdl4oCZdmUgYXQg bGVhc3QgcHJvdmlkZWQgYSBzb2x1dGlvbiBmb3IgdGhvc2UgdXNhZ2Ugc2NlbmFyaW9zIHdoZXJl IHRoZSBuZXR3b3JrIGlzIHRydXN0ZWQuIFJpZ2h0IG5vdywgd2XigJlyZSBob2xkaW5nIOKAnG5l dHdvcmtzIHRydXN0ZWQgYnkgdGhlIHVzZXIvYWRtaW7igJ0NCiBob3N0YWdlIHVudGlsIHNvbWUg Y29udm9sdXRlZCBzb2x1dGlvbiBjYW4gYmUgY3JlYXRlZCB0aGF0IGFkZHMgY29tcGxleGl0eSBh bmQgY29uZnVzaW9uIGZvciB0aGUgdXNlciBhbmQgb25seSBzZXJ2ZXMgdG8gc2hpZnQgd2hvIHRo ZSB1c2VyL2FkbWluIGhhcyB0byB0cnVzdCAoYnV0IGRvZXNu4oCZdCBuZWNlc3NhcmlseSBtYWtl IHRoaW5ncyBtb3JlIHNlY3VyZSBvciBwcml2YXRlKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjRwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9UT0gsIGlm IHdlIGNvdWxkIGZpZ3VyZSBzb21ldGhpbmcgb3V0IHRoYXQgaXMgc2ltcGxlIChlc3BlY2lhbGx5 IGZvciB0aGUgdXNlcikgYW5kIGRvZXNu4oCZdCBqdXN0IHNoaWZ0IHdobyB0aGUgdXNlci9hZG1p biBoYXMgdG8gdHJ1c3QsIHRoYXQgd291bGQgZGVmaW5pdGVseSBiZSB1c2VmdWwgdG8gZXhwbG9y ZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJhcmJhcmEgJmx0Oy9iaHMmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+VGhpcyBzZWVtcyBl bnRpcmVseSBzZW5zaWJsZTogYXNzdW1pbmcgdGhhdCBubyBuZXR3b3JrIGNhbiBldmVyIGJlIHRy dXN0ZWQgaXMgY2xlYXJseSBub3Qgc2Vuc2libGUsIGFzIGlzIHJ1bGluZyBvdXQgYW4gb3B0aW9u IGF0IHRoaXMgc3RhZ2UuJm5ic3A7IEl0IGNvdWxkIHNpbXBsaWZ5IG1hbnkgdXNlIGNhc2VzIHRv IGRvIHNvIGFuZCB3b3VsZA0KIGF2b2lkIGZvcmNpbmcgdGhlIHVzZXIgdG8gdHJ1c3QgYW5vdGhl ciBlbnRpdHkgdW5uZWNlc3NhcmlseSB3aGVuIGRvaW5nIHNvIGhhcyB0aGUgcG90ZW50aWFsIHRv IGludHJvZHVjZSBhZGRpdGlvbmFsIHJpc2suJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFuZHJldyA8bzpwPjwvbzpwPjwv c3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_LO2P265MB05737EAD1F099B43B31A46EAC2390LO2P265MB0573GBRP_-- From nobody Thu Jan 9 14:43:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC631120827 for ; Thu, 9 Jan 2020 14:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 35ZAqEhUPLAR for ; Thu, 9 Jan 2020 14:43:50 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 09D4C120825 for ; Thu, 9 Jan 2020 14:43:50 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id a33so8880pgm.5 for ; Thu, 09 Jan 2020 14:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HGU6yZgbjaILxuNG7BP60Slb84r5sJBq4mcblpgwXTw=; b=G6Vy5cSQVg9CN6FzRFEMXGDf3zqFZrgOEU6sAo4TMsCl6q5Gb0/CIW9dbdGqLfGQSl ZkTG4+jmjqyYFJTu57iuwJy/y5Xa3c+gineQz+SD2770AQoOGFXyOwTTgQfjlAdsLUI/ 5IuKC5BqouK+L5jjEPieppsIWHqhfUUlBu9Bm14m4P92vhTeGHxjkTkVCwThP06oaaxA UWfAgY1SrqUKi0WlzSp7VPhPq8eg6cakP2MJJojkHqqLDwtKNSNP44Ie3NFd/+tNBRVQ d8jJLZFH82vO5Cx6VlVzuNMqG0GEVdG4tR7b7inDlG1jBHdT23hkhwn02ZY9FgwCMHjC rbRw== 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=HGU6yZgbjaILxuNG7BP60Slb84r5sJBq4mcblpgwXTw=; b=p8lawdvV8NUJ874XRxW8gM19UpFvlnkk6YbAIJZ1J0fVD5mJbU7TONpn+OFrGdTrZZ vv4f9F58g5RimMSSE0krcL32+71laBXKmylnkFRn2vtphwGUDBGtlvP/9k1HLkBDpdCX gjAnZ5Q1mMCy802Qyx7tgxE5B89OYUELtwMx46IWw+0ZU6DryvOwfwU91LlOjcwxUrQO iYPhNVVQO+sUNA5wrDjGEot/P6OZdWZkfkiWs4U7GxXgqfSR9p68+cLVI2gUk+DtKbfX mwTggGdo8ixrg/U91JCs5qakdale0+8nC2OdJHeiZFMX1PYBvx6866W54i9XPoSeOATo 9aEg== X-Gm-Message-State: APjAAAXbofc+6SzO2oUBVUAtRGHU53uyWJVpHMcGa8WUkQnjthzIZ6c5 Wu8bVYilZmx/QRsgkWpGemDuKA== X-Google-Smtp-Source: APXvYqwMlULmMRg8dGmwsjfs+Auggb4DPUOJ3QGks2Xg+yTZIdYuIoWN58S27XytzoXlIFoEI7n0ag== X-Received: by 2002:a63:a84a:: with SMTP id i10mr410314pgp.6.1578609829558; Thu, 09 Jan 2020 14:43:49 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.170.45]) by smtp.gmail.com with ESMTPSA id y14sm52655pfe.147.2020.01.09.14.43.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 14:43:48 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B2BF1BF6-13B2-4713-92B5-9500EA471F38" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Thu, 9 Jan 2020 14:43:47 -0800 In-Reply-To: Cc: "STARK, BARBARA H" , ADD Mailing list To: Andrew Campling References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 22:43:53 -0000 --Apple-Mail=_B2BF1BF6-13B2-4713-92B5-9500EA471F38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 9, 2020, at 2:39 PM, Andrew Campling = wrote: > This seems entirely sensible: assuming that no network can ever be = trusted is clearly not sensible, as is ruling out an option at this = stage. It could simplify many use cases to do so and would avoid = forcing the user to trust another entity unnecessarily when doing so has = the potential to introduce additional risk. =20 There is definite harm in making a charter broader than it needs to be. = If it turns out that we scoped it too narrowly, then when we have a = specific use case that we agree is important but that is outside of the = initial scope, we can broaden it. This is happens frequently in the = IETF. There is no need to ever specify an overly broad charter. --Apple-Mail=_B2BF1BF6-13B2-4713-92B5-9500EA471F38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 9, 2020, at 2:39 PM, Andrew Campling <andrew.campling@419.consulting> wrote:
This seems entirely sensible: = assuming that no network can ever be trusted is clearly not sensible, as = is ruling out an option at this stage.  It could simplify many use = cases to do so and would avoid forcing the user to trust another entity = unnecessarily when doing so has the potential to introduce additional = risk.   

There is definite harm in making a charter broader than it = needs to be.   If it turns out that we scoped it too narrowly, then = when we have a specific use case that we agree is important but that is = outside of the initial scope, we can broaden it.   This is happens = frequently in the IETF.   There is no need to ever specify an = overly broad charter.

= --Apple-Mail=_B2BF1BF6-13B2-4713-92B5-9500EA471F38-- From nobody Thu Jan 9 14:50:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB6F120830 for ; Thu, 9 Jan 2020 14:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 R3XYy6uM3Xxx for ; Thu, 9 Jan 2020 14:50:19 -0800 (PST) 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 5AEF0120807 for ; Thu, 9 Jan 2020 14:50:19 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id v3so9008996ioj.5 for ; Thu, 09 Jan 2020 14:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uVpedh1f1cfpQSzwgKsaUT+j3V7Nd4yi+ZSwXc6s3KU=; b=TZ/+sZhMyGw+ucLQ7j4FYQcSklDeJHhp3e7F0giyvI1d/jiimzApQQZO2vRdAe+fjS ug+DSBzXpob/+razHbYv5F1DKsvV5Lb/u2/QXMvF4mV9pukiAJ6WMlafbOC2N5RlITNB Fb1nWJ2FHxJqNrM9tG5ZLlCVI5QQNkolRSijEpv77gwt+jBeTcEqFXbbTbnHIEYn+AKd u2fG4Ljypu3lE+3KGunQNEXnKZ1QxpJbtHF9RnJpEncJWBknpMxc5JWrWLlWOfFVV0Sl F+pepm19qgUKfpGoPDDSjnFEIuXgICalJ1Y0pTpS+tn4TnyBSjKPsWcA5UWpyJMxqdHg 4rqg== 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=uVpedh1f1cfpQSzwgKsaUT+j3V7Nd4yi+ZSwXc6s3KU=; b=osLnCX4+J4kYsdxDZwNS1YVqGW/LNAF7kSUBvyJqgudmuyYhsbEOPPGUamqvU8K8DH mcfOuQZSHdwKl99rpW7THqkgMH7ddN3gC5rI77z4bwpdkS+d7I6hn2T15+hpzucykSUk bbSAYvoUgHvQzHJRtNFSVOgwvjpidc0Vq/NIqbrjDccipxhrJXToYKSJ0+Gyh7+CoY07 KVxtXuXscuAI5TJ9ibFnZg7KKmotsSYu13Ba4f6ZyTQPYpsow4oZiq3K8MdBqp7f1sNT QLwFkX0siEKH34VbvBpeH+z0NMGCZdF1Wv+VhWHMdDrZ1yK36EE5HJCiAmUD73BdWxsb k3NA== X-Gm-Message-State: APjAAAU5zFFXNj3O3eN2I7TVtuPfYLuviIH9yNlrGT1mOzCZLw5HffJb MqPZQsmWL+uk74H4ezPqSJ2/XVeXAwKyqxy9RSE94qQnTEtJ5A== X-Google-Smtp-Source: APXvYqzwRllJD7nB3t0c0Q4w0jmiRt3acPQqbAvjaGwdXuMD266VbbYOOqWG6Q1SDiiRi3TAQk6mWGD/YmjIEtbUnkQ= X-Received: by 2002:a02:b893:: with SMTP id p19mr26806jam.103.1578610218516; Thu, 09 Jan 2020 14:50:18 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: From: Rob Sayre Date: Thu, 9 Jan 2020 14:50:07 -0800 Message-ID: To: Andrew Campling Cc: "STARK, BARBARA H" , Ted Lemon , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000504604059bbcd516" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 22:50:21 -0000 --000000000000504604059bbcd516 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 Andrew Campling wrote: > This seems entirely sensible: assuming that no network can ever be trusted > is clearly not sensible, as is ruling out an option at this stage. It could > simplify many use cases to do so and would avoid forcing the user to trust > another entity unnecessarily when doing so has the potential to introduce > additional risk. "Endpoints should not depend on the confidentiality or integrity of the carriers. Carriers may choose to provide some level of protection, but this is secondary to the primary responsibility of the end users to protect themselves." RFC 1958 Architectural Principles of the Internet June 1996 thanks, Rob --000000000000504604059bbcd516 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 9, 2020 Andrew Campling <andrew.campling@41= 9.consulting> wrote:
> This seems entirely sensible: assuming that= no network can ever be trusted
> is clearly not sensible, as is rul= ing out an option at this stage.=C2=A0 It could
> simplify many use c= ases to do so and would avoid forcing the user to trust
> another en= tity unnecessarily when doing so has the potential to introduce
> add= itional risk.

"Endpoints should not depend on the confidentiali= ty or integrity of the
carriers. Carriers may choose to provide some le= vel of protection, but this
is secondary to the primary responsibility = of the end users to protect
themselves."

RFC 1958
Archite= ctural Principles of the Internet
June 1996

thanks,
Rob
--000000000000504604059bbcd516-- From nobody Thu Jan 9 15:05:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D78F120816 for ; Thu, 9 Jan 2020 15:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2ibXro4wZZl for ; Thu, 9 Jan 2020 15:05:30 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01983120825 for ; Thu, 9 Jan 2020 15:05:29 -0800 (PST) Received: from pps.filterd (m0047964.ppops.net [127.0.0.1]) by m0047964.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 009N0grf029021 for ; Thu, 9 Jan 2020 18:05:29 -0500 Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0047964.ppops.net-00176a04. with ESMTP id 2xaq6cepkt-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 09 Jan 2020 18:05:29 -0500 Received: from unknown (HELO ashemwp00046.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 09 Jan 2020 15:05:27 -0800 Received: from ashemwp00047.mail.tfayd.com (100.126.24.71) by ashemwp00041.mail.tfayd.com (100.126.24.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 18:05:26 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00047.mail.tfayd.com (100.126.24.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 18:05:25 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 9 Jan 2020 18:05:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mNYrpCtVCdOzekQYCLYRwkVdjhQvh8P/1l901kREU6b2gYFTnPn5TYgH+x5LUZy/cBf0naGH1/lFhOKDf+xoAjuEq/wFOTX9f3QIzid4G5PyLG1i1s7CGdy9qvqXpvE3PzEL4P6RSRDAIkef/0lx3OEs1/Lbm4Fo1WJjy9c1OfyJebW2hY6RkUHZH8EbJjxflRtTaSXmf09fh+8jtVOyluPed8gtxfx+ma4g4Z7RUPmvF2YB/tw2/8Xd2XpkVxW8RQ/zfFSVOVtIpvj8ADZFhSG9xq0oKAsIJBICCxY4a1klJwjmyUdaDUaHAjxjqYb5/hOT1SrG6WCH+Ffrl+oFOA== 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=vOPLyxbqa1G9KR8rtqfvTFAX4SFXx36cds4XrsnT2EY=; b=Vp+wn7Wk+AB/PGgw/qgcRAAbMw/3DQ7iHj0DmYxKNMySYAxDIUXABfySOvDVv4U1ne+Ed9DttxJtjbU/lH9ETHNuapMd+NyRcgvoLYz9zlAAFUSN7ed3DCt8pL3JoyfzcCbDCgkVCG6gTXdTBGHotLHoava9OfgyDtixRWH1m7jFugoXOFsK3BH1Tk1uPkPCb53izSzlWA7TGsD4y7Leq3NnlieUCAOJXHtBWqQml/dKnlkL55gUxo/n1CGLasKM2iE7gamHgndYYQTvZqVMu56tdF0sDvAVkuA8EQrkjFZ7kY8K8mDIuP8fMn/OmbLMgPjm76HvDft2u0oBTplnBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vOPLyxbqa1G9KR8rtqfvTFAX4SFXx36cds4XrsnT2EY=; b=CAkI4mvpNnG5y72KnTDcgs5x7SmgdC/re668f+eHHgL9OuaZ+Zz8xXBhhCB2bbA8YBAwp05ZIEizK0PASPHEiFqHCL5C99imWzluQJYXfGxrEJ53XaJYj6u7msRLhO1p1jNpRjUgtWJx48LxcNRXbhEibxxfeZZTtihZViG8te0= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB2393.namprd14.prod.outlook.com (20.176.91.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Thu, 9 Jan 2020 23:05:23 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 23:05:23 +0000 From: "Deen, Glenn (NBCUniversal)" To: Rob Sayre , Tommy Pauly CC: Vittorio Bertola , ADD Mailing list , Mirja Kuehlewind , Stephen Farrell , "Deen, Glenn (NBCUniversal)" Thread-Topic: [EXTERNAL] Re: [Add] A proposed charter for ABCD Thread-Index: AQHVxysdTY9pjqmcaE+ILgeg0ueHRKfiyveAgAABiYD//6GYgA== Date: Thu, 9 Jan 2020 23:05:23 +0000 Message-ID: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.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.20.0.191208 x-originating-ip: [69.241.73.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbb70de0-c2ba-4348-ecfa-08d795586879 x-ms-traffictypediagnostic: DM6PR14MB2393: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(136003)(39860400002)(199004)(189003)(4326008)(8936002)(966005)(478600001)(8676002)(53546011)(6506007)(81166006)(81156014)(2906002)(6512007)(6486002)(86362001)(107886003)(36756003)(71200400001)(186003)(66446008)(33656002)(64756008)(76116006)(91956017)(66476007)(110136005)(54906003)(66946007)(2616005)(5660300002)(66556008)(26005)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB2393; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2zI5R71Zpno0iriSo+0gc0e8cBsRoY7BtjfOcho7qrYc0ROoBeqtQKv6KjmkgpA661PaP5AqVi+O/CP4QtgZiZXWiptHCRre7wIbV8XVyuyiLpTx6q/mfDNqmHHPcv7Pg4X4jAhoSdl/jkRSY1vVTQf59k+DBxxC6uzwV9xTnqGOiKlAKQXsqdkODZDzhs0AuYbGcIalBjh5FdA1JTyL103OpJGE4fXRhUHRFYgVJuRYe4RTmg9pEMjg/16u0Bmd0GsZ+c3Pc/hIjMlaxoX5qG6jAGGydF8/AFR4X8TVyzYcHu6ZDWX3rKROEw/OshL6olwgKMVNwdQBYHLDXfr9D05IYcnlLKLJQdtRr3+MR/jwJ8uZqvl5T2kAQa8sUHoy54farr78DhqHi1SGx3QmYbbt0N05VG/Tx+rNSuWrotGaxSGdjUyF9fUMeARTwbebx7aV1p0YzSKtwoBMonIDuxJb0ieuftBoIh9aDi6ie9r+I1qdsMKugMGG6RIiBMtsfxiIgJvYiGuQ/Ov+mgngmQ== Content-Type: multipart/alternative; boundary="_000_43AEEA2D1BDB4A56BC32A89A96588951nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dbb70de0-c2ba-4348-ecfa-08d795586879 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 23:05:23.8357 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8QeIluk96NHq9ImfZBqSOzqxRI9Y1YG7RCv/C6ASORce4bNuI9z3IXMZI4l5mgjckK7an8nuUMW+g9SPyuNFkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB2393 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_05:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 clxscore=1015 bulkscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090192 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 23:05:31 -0000 --_000_43AEEA2D1BDB4A56BC32A89A96588951nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgUm9iDQoNCk9uIDEvOS8yMCwgMTI6NDQgUE0sICJSb2IgU2F5cmUiIDxzYXlyZXJAZ21haWwu Y29tPG1haWx0bzpzYXlyZXJAZ21haWwuY29tPj4gd3JvdGU6DQpPbiBUaHUsIEphbiA5LCAyMDIw IGF0IDEyOjM4IFBNIFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+IE9uIEphbiA5 LCAyMDIwLCBhdCAxMjoyNiBQTSwgRGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkgPEdsZW5uLkRl ZW5AbmJjdW5pLmNvbTxtYWlsdG86R2xlbm4uRGVlbkBuYmN1bmkuY29tPj4gd3JvdGU6DQo+IE9u IDEvOC8yMCwgNToyMSBBTSwgIkFkZCBvbiBiZWhhbGYgb2YgTWlyamEgS3VlaGxld2luZCIgPGFk ZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+PiB3cm90 ZToNCj4NCj4gICAgSGkgVml0dG9yaW8sDQo+DQo+ICAgIFRoZSBjaGFydGVyIHByb3Bvc2VkIGJ5 IFRvbW15IChzZWUgWzFdKSBpcyBleGFjdGx5IGZvY3VzaW5nIG9uIGRpc2NvdmVyeSBhbmQgc2Vs ZWN0aW9uLiBXaGF0IGFyZSB5b3UgbWlzc2luZyB0aGVyZT8NCj4NCj4gICAgTWlyamENCj4NCj4g ICAgWzFdIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL2FkZC9YdWRHNWlkMHd3ZFJuZFI1emE0RzlaYkNvX3dfXzshIVBJWmVl VzV3c2N5blJRITZWSWRhLVdtOXpIYzljQ3JBMmY2cmIyQ0E3elNDZm9xYTN6bWUyRVZlc01COVp2 dmJWUFhrYU1PZWZyS0xwNV8kPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWRkL1h1ZEc1aWQwd3dkUm5kUjV6YTRHOVpiQ29f d19fOyEhUElaZWVXNXdzY3luUlEhNlZJZGEtV205ekhjOWNDckEyZjZyYjJDQTd6U0Nmb3FhM3pt ZTJFVmVzTUI5WnZ2YlZQWGthTU9lZnJLTHA1XyQ+DQo+DQo+IFdoaWxlIEkgYWdyZWUgdGhhdCBp dCBpcyBmb2N1c2VkIG9uIEQmUyBpdCBpbmNsdWRlcyB0ZXh0IGF0IHRoZSBlbmQgcHVsbGluZyBp biBkcmFmdC1wYXVseS1kcml2ZS1hZGFwdGl2ZS1kbnMtcHJpdmFjeSBhcyBhIHN0YXJ0aW5nIHBv aW50LiBUaGF0IHRha2VzIGlzIGJleW9uZCBqdXN0IEQgJiBTIGFuZCBpbnRvIG1vcmUgYWR2YW5j ZWQgYmVoYXZpb3Igb2YgcmVzb2x2ZXJzIGFzIGRyYWZ0LXBhdWx5LWRyaXZlLWFkYXB0aXZlLWRu cy1wcml2YWN5IGdvZXMgYmV5b25kIGp1c3QgRCZTLg0KDQpJJ20gdmVyeSBoYXBweSB0byByZW1v dmUgdGhpcyBsaW5l4oCUdGhhdCB3YXMgbWFpbmx5IHRoZXJlIHRvIHJlc3BvbmQgdG8gcGVvcGxl IHdobyBoYWQgYXNrZWQgd2hhdCBhIGNoYXJ0ZXIgd291bGQgbG9vayBsaWtlIHRoYXQgd2FzIGJh c2VkIG9uIHRoaXMgZHJhZnQuDQoNCj4NCj4gQXMgSSBzYWlkIGluIG15IG90aGVyIG5vdGUsIEkg dGhpbmsgaXQncyB0aGUgYWRkaW5nIG9mIHRoZXNlIHN0YXJ0aW5nIHBvaW50cyB0aGF0IG1heWJl IGNhdXNpbmcgYSBsb3Qgb2YgdGhlIGlzc3VlcyBjb21pbmcgdG8gY2xvc3VyZS4gICBUb21teSdz IHByb3Bvc2FsIGRvZXMgZ2l2ZSB0aGUgV0cgdGhlIG9wdGlvbiBhcyBoZSBzYXlzIGl0IGlzIHN1 YmplY3QgdG8gdGhlIFdHJ3MgZGVzaWduIGNob2ljZXMuICBBIGNvbmNlcm4gY291bGQgYmUgaWYg dGhlIHRleHQgYWJvdXQgaXQgYmVpbmcgYW4gb3B0aW9uIGRpc2FwcGVhcmVkIGFuZCBpdCBiZWNh bWUgYSByZXF1aXJlbWVudCB0byB0YWtlIG9uIHRoZSBtYXRlcmlhbCBpbiB0aGF0IGRyYWZ0IHRo YXQgZ29lcyBiZXlvbmQgRCZTIGFuZCBpbnRvIHJlc29sdmVyIGJlaGF2aW9yLg0KDQpJIHRoaW5r IGlmIHdlIGNhbiBhZ3JlZSBvbiB0aGUgc2V0IG9mIGRlbGl2ZXJhYmxlcyBhbmQgd29yayBhcmVh cywgd2UgY2FuIGZvcmVnbyBzcGVjaWZ5aW5nIGFueSBwYXJ0aWN1bGFyIGRyYWZ0LiBUaGF0IGNl cnRhaW5seSBjYW4gYW5kIHNob3VsZCBiZSB0aGUgd29yayBvZiB0aGUgV0cgdG8gZGVjaWRlLg0K DQpBcGFydCBmcm9tIHRoYXQgc3RhcnRpbmcgcGxhY2UsIHdoYXQgb3RoZXIgY2hhbmdlcyB3b3Vs ZCBiZSBhcHByb3ByaWF0ZT8NCg0KSSdtIG5vdCBzdXJlIHdoYXQgR2xlbm4gbWVhbnMgYnkgInJl c29sdmVyIGJlaGF2aW9yIi4gRG9lcyB0aGF0IG1lYW4gY2xpZW50IGJlaGF2aW9yPyBJIGxvb2tl ZCBhdCB0aGUgZHJhZnQgYWdhaW4gYW5kIGRpZG4ndCBmaW5kIGFueSByZXF1aXJlbWVudHMgb24g c2VydmVycyB0aGF0IHdvdWxkIGJlIGluY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIGltcGxlbWVu dGF0aW9ucywgdGhvdWdoIG9mIGNvdXJzZSB0aGVyZSBhcmUgc29tZSBuZXcgY2FwYWJpbGl0aWVz IGFyb3VuZCBkaXNjb3ZlcnkgYW5kIHNlbGVjdGlvbi4NCg0KW0dEXSBJIHdhcyByZWZlcnJpbmcg dG8gdGhlIHNlY3Rpb24gb24gc2VydmVyIGJlaGF2aW9yIGluIHNlY3Rpb24gNCBvZiB0aGUgZHJh ZnQuICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGF1bHktZHByaXZlLWFkYXB0 aXZlLWRucy1wcml2YWN5LTAxDQoNCk15IG9iamVjdGlvbiBiZWluZyB0aGF0IGl04oCZcyBvdXQg b2Ygc2NvcGUgZm9yIGEgV0cgZm9jdXNlZCBvbiBEJlMsIGl0IGlzIGFuIGludGVyZXN0aW5nIGRp c2N1c3Npb24gYnV0IEkgdGhpbmsgZml0cyBpbnRvIERQUklWLg0KDQpUaGVyZSBhcmUgb3RoZXIg YXNwZWN0cyBvZiB0aGUgZHJhZnQgdGhhdCBJIHRoaW5rIHdvdWxkIHdvcmsgaWYgYnJva2VuIG91 dCBpbnRvIGEgY2xpZW50IEQmUyBkcmFmdCB0aGF0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIGZvciBh IEQmUyBXRy4NCg0KDQotZ2xlbm4NCg== --_000_43AEEA2D1BDB4A56BC32A89A96588951nbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3A880DE1DEC8A44DBDC84DDFDF05FEFB@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAyIDYgMyA1 IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpI ZWx2ZXRpY2E7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPkhJIFJvYjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRp Y2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIDEvOS8yMCwgMTI6NDQgUE0s ICZxdW90O1JvYiBTYXlyZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNheXJlckBnbWFpbC5j b20iPnNheXJlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gVGh1LCBKYW4gOSwgMjAyMCBhdCAxMjozOCBQTSBUb21t eSBQYXVseSAmbHQ7dHBhdWx5PTxhIGhyZWY9Im1haWx0bzo0MGFwcGxlLmNvbUBkbWFyYy5pZXRm Lm9yZyI+NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mZ3Q7IE9uIEphbiA5LCAyMDIwLCBhdCAxMjoyNiBQTSwgRGVlbiwg R2xlbm4gKE5CQ1VuaXZlcnNhbCkgJmx0OzxhIGhyZWY9Im1haWx0bzpHbGVubi5EZWVuQG5iY3Vu aS5jb20iIHRhcmdldD0iX2JsYW5rIj5HbGVubi5EZWVuQG5iY3VuaS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7IE9uIDEvOC8yMCwgNToyMSBBTSwgJnF1b3Q7QWRkIG9uIGJlaGFsZiBvZiBN aXJqYSBLdWVobGV3aW5kJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRkLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hZGQtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm IG9mDQo8YSBocmVmPSJtYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PmlldGZAa3VlaGxld2luZC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsgJm5ic3A7IEhpIFZpdHRvcmlvLDxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgVGhlIGNoYXJ0ZXIgcHJvcG9zZWQgYnkgVG9tbXkgKHNlZSBbMV0pIGlzIGV4YWN0bHkgZm9j dXNpbmcgb24gZGlzY292ZXJ5IGFuZCBzZWxlY3Rpb24uIFdoYXQgYXJlIHlvdSBtaXNzaW5nIHRo ZXJlPzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgTWlyamE8YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7IFsxXSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FkZC9YdWRHNWlkMHd3 ZFJuZFI1emE0RzlaYkNvX3dfXzshIVBJWmVlVzV3c2N5blJRITZWSWRhLVdtOXpIYzljQ3JBMmY2 cmIyQ0E3elNDZm9xYTN6bWUyRVZlc01COVp2dmJWUFhrYU1PZWZyS0xwNV8kIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9hZGQvWHVkRzVpZDB3d2RSbmRSNXphNEc5WmJDb193X187ISFQSVpl ZVc1d3NjeW5SUSE2VklkYS1XbTl6SGM5Y0NyQTJmNnJiMkNBN3pTQ2ZvcWEzem1lMkVWZXNNQjla dnZiVlBYa2FNT2VmcktMcDVfJDwvYT4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGlsZSBJIGFn cmVlIHRoYXQgaXQgaXMgZm9jdXNlZCBvbiBEJmFtcDtTIGl0IGluY2x1ZGVzIHRleHQgYXQgdGhl IGVuZCBwdWxsaW5nIGluIGRyYWZ0LXBhdWx5LWRyaXZlLWFkYXB0aXZlLWRucy1wcml2YWN5IGFz IGEgc3RhcnRpbmcgcG9pbnQuIFRoYXQgdGFrZXMgaXMgYmV5b25kIGp1c3QgRCAmYW1wOyBTIGFu ZCBpbnRvIG1vcmUgYWR2YW5jZWQgYmVoYXZpb3Igb2YgcmVzb2x2ZXJzIGFzIGRyYWZ0LXBhdWx5 LWRyaXZlLWFkYXB0aXZlLWRucy1wcml2YWN5DQogZ29lcyBiZXlvbmQganVzdCBEJmFtcDtTLjxi cj4NCjxicj4NCkknbSB2ZXJ5IGhhcHB5IHRvIHJlbW92ZSB0aGlzIGxpbmXigJR0aGF0IHdhcyBt YWlubHkgdGhlcmUgdG8gcmVzcG9uZCB0byBwZW9wbGUgd2hvIGhhZCBhc2tlZCB3aGF0IGEgY2hh cnRlciB3b3VsZCBsb29rIGxpa2UgdGhhdCB3YXMgYmFzZWQgb24gdGhpcyBkcmFmdC48YnI+DQo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgSSBzYWlkIGluIG15IG90aGVyIG5vdGUsIEkgdGhpbmsg aXQncyB0aGUgYWRkaW5nIG9mIHRoZXNlIHN0YXJ0aW5nIHBvaW50cyB0aGF0IG1heWJlIGNhdXNp bmcgYSBsb3Qgb2YgdGhlIGlzc3VlcyBjb21pbmcgdG8gY2xvc3VyZS4mbmJzcDsgJm5ic3A7VG9t bXkncyBwcm9wb3NhbCBkb2VzIGdpdmUgdGhlIFdHIHRoZSBvcHRpb24gYXMgaGUgc2F5cyBpdCBp cyBzdWJqZWN0IHRvIHRoZSBXRydzIGRlc2lnbiBjaG9pY2VzLiZuYnNwOyBBIGNvbmNlcm4gY291 bGQgYmUNCiBpZiB0aGUgdGV4dCBhYm91dCBpdCBiZWluZyBhbiBvcHRpb24gZGlzYXBwZWFyZWQg YW5kIGl0IGJlY2FtZSBhIHJlcXVpcmVtZW50IHRvIHRha2Ugb24gdGhlIG1hdGVyaWFsIGluIHRo YXQgZHJhZnQgdGhhdCBnb2VzIGJleW9uZCBEJmFtcDtTIGFuZCBpbnRvIHJlc29sdmVyIGJlaGF2 aW9yLjxicj4NCjxicj4NCkkgdGhpbmsgaWYgd2UgY2FuIGFncmVlIG9uIHRoZSBzZXQgb2YgZGVs aXZlcmFibGVzIGFuZCB3b3JrIGFyZWFzLCB3ZSBjYW4gZm9yZWdvIHNwZWNpZnlpbmcgYW55IHBh cnRpY3VsYXIgZHJhZnQuIFRoYXQgY2VydGFpbmx5IGNhbiBhbmQgc2hvdWxkIGJlIHRoZSB3b3Jr IG9mIHRoZSBXRyB0byBkZWNpZGUuPGJyPg0KPGJyPg0KQXBhcnQgZnJvbSB0aGF0IHN0YXJ0aW5n IHBsYWNlLCB3aGF0IG90aGVyIGNoYW5nZXMgd291bGQgYmUgYXBwcm9wcmlhdGU/PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkknbSBub3Qgc3Vy ZSB3aGF0IEdsZW5uIG1lYW5zIGJ5ICZxdW90O3Jlc29sdmVyIGJlaGF2aW9yJnF1b3Q7LiBEb2Vz IHRoYXQgbWVhbiBjbGllbnQgYmVoYXZpb3I/IEkgbG9va2VkIGF0IHRoZSBkcmFmdCBhZ2FpbiBh bmQgZGlkbid0IGZpbmQgYW55IHJlcXVpcmVtZW50cyBvbiBzZXJ2ZXJzIHRoYXQgd291bGQgYmUg aW5jb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLA0KIHRob3VnaCBvZiBj b3Vyc2UgdGhlcmUgYXJlIHNvbWUgbmV3IGNhcGFiaWxpdGllcyBhcm91bmQgZGlzY292ZXJ5IGFu ZCBzZWxlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNh Ij5bR0RdIEkgd2FzIHJlZmVycmluZyB0byB0aGUgc2VjdGlvbiBvbiBzZXJ2ZXIgYmVoYXZpb3Ig aW4gc2VjdGlvbiA0IG9mIHRoZSBkcmFmdC4mbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXVseS1kcHJpdmUtYWRhcHRpdmUtZG5zLXByaXZhY3ktMDEi Pg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdWx5LWRwcml2ZS1hZGFwdGl2 ZS1kbnMtcHJpdmFjeS0wMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6SGVsdmV0aWNhIj5NeSBvYmplY3Rpb24gYmVpbmcgdGhhdCBpdOKAmXMgb3V0IG9mIHNj b3BlIGZvciBhIFdHIGZvY3VzZWQgb24gRCZhbXA7UywgaXQgaXMgYW4gaW50ZXJlc3RpbmcgZGlz Y3Vzc2lvbiBidXQgSSB0aGluayBmaXRzIGludG8gRFBSSVYuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGlj YSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhlcmUgYXJlIG90aGVyIGFzcGVjdHMg b2YgdGhlIGRyYWZ0IHRoYXQgSSB0aGluayB3b3VsZCB3b3JrIGlmIGJyb2tlbiBvdXQgaW50byBh IGNsaWVudCBEJmFtcDtTIGRyYWZ0IHRoYXQgd291bGQgYmUgYXBwcm9wcmlhdGUgZm9yIGEgRCZh bXA7UyBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0 aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4tZ2xlbm48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_43AEEA2D1BDB4A56BC32A89A96588951nbcunicom_-- From nobody Thu Jan 9 15:10:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69DE120831 for ; Thu, 9 Jan 2020 15:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiWFsEOsaBKm for ; Thu, 9 Jan 2020 15:10:46 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (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 A29AE120830 for ; Thu, 9 Jan 2020 15:10:46 -0800 (PST) Received: from pps.filterd (m0048207.ppops.net [127.0.0.1]) by m0048207.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 009MuAjf040592 for ; Thu, 9 Jan 2020 17:56:36 -0500 Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0048207.ppops.net-00176a04. with ESMTP id 2xapujx6e1-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 09 Jan 2020 17:56:35 -0500 Received: from unknown (HELO ashemwp00047.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 09 Jan 2020 14:56:33 -0800 Received: from ashemwp00006.mail.tfayd.com (100.126.24.30) by ashemwp00009.mail.tfayd.com (100.126.24.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 17:56:27 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00006.mail.tfayd.com (100.126.24.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 9 Jan 2020 17:56:26 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Thu, 9 Jan 2020 17:56:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DLOvPvONJTPIRwWFpBV8Zj288It4yBBZr9K9sGDF6SN2yRxhqpp8jfIDZY3Avd7aLYT365lpkSHKFH6x+Vw4OopBcub1ybV7LPo2Jvc0lZ+vE3kPUK8eSTJxp0qRY3A3oD6BPqwW6Zhz78pXQeXQRjnZ7CEG6A/1yubxswZCoRrd0fVS5QoVl9yqhEPVnzHKKGpaaaus+qWAByfZxsQnHOOV//0wObnxlHyrTUQSM+mZ8dDX1TZ2RCDaI0p7P8JjWr1C7mCP+8B3uSOv/cmeU87ZrRqYApRDYI/gAYu984BFTAbwZJMLUpDb2clL8ujnTw+Z1eGgp2VtY3l1dpjvxA== 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=B3vIKID5aGwh4VCR3M50wS+p91E1V1/NLEm9dhtrUWo=; b=Tf21enCtasgkUSBi0ZiBbVaPv76evA2kWKBb1pBb2OF/+mLuFuDXlxTvCOQDInx4f8so2BDc3f6iPG1SAOKDTpGNYETqVhwJ13qkP4KldnJDATQspgotD/tDpoanQlnunDa8El7U/P7BU5fLIYfitxGXJkNWrM4jp5YtV/6tUACV4TKyWHi42hbeWfsdZtlV0Dj/d9dEHi+K7uGuWM2DiHw72rv5IKb+PN7vpWiHKdbcSgc+COCgZ/Ptbt3W92lyCXKJcI6ojANmleerbF5dIksVEidFtXxCFX3LlZGMQNMsAY3NLEpRnlD4HGdn5Ntnt4Bk+rRTT3wWHjvC0vQNtQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B3vIKID5aGwh4VCR3M50wS+p91E1V1/NLEm9dhtrUWo=; b=y+frE16P0JEfxOrV85t6F1VJqH8+DK6+ZD+EG/zhD/XwsbjfUomcxJgfDW7ikU17RtZ9KImVpn7s7JmIsRKOqC7w3xoVfv7rNqlMG6ZwV8Rze2f+BvYKpcYNukbib55GCrhS7PG07d32I5xUJ2eclBJHnN4zSZEKrWoUN6zZzaU= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB4091.namprd14.prod.outlook.com (10.141.8.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Thu, 9 Jan 2020 22:56:25 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 22:56:25 +0000 From: "Deen, Glenn (NBCUniversal)" To: Ted Lemon , Alissa Cooper CC: Ben Schwartz , ADD Mailing list , =?Windows-1252?Q?=22Mirja_K=FChlewind_=28IETF=29=22?= , Stephen Farrell , "Deen, Glenn (NBCUniversal)" Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxz9JmWuBpd+SzUuSPFqRPFm94g== Date: Thu, 9 Jan 2020 22:56:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [69.241.73.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a769d8e2-6329-4785-5fb0-08d7955727b7 x-ms-traffictypediagnostic: DM6PR14MB4091: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39860400002)(346002)(376002)(136003)(199004)(189003)(478600001)(4326008)(36756003)(107886003)(2616005)(71200400001)(966005)(66946007)(33656002)(2906002)(6512007)(6486002)(19627405001)(66556008)(76116006)(66446008)(64756008)(66476007)(53546011)(6506007)(186003)(110136005)(8936002)(316002)(26005)(86362001)(54906003)(81156014)(81166006)(8676002)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB4091; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ch/VkiqXIDGbNlccEeGKTv3gpHKy+gPN1EctTuJgScaacjbUadPsP9/0K16gAUUfoYpyoyVbFLg+URwHvHudbZA0uWdTQkqd33g0eeTXjycr/iJTJIrR+pVJn2+MkGEDRaaRc9FjYSe+ar8SJb10KCQqkXHd6Mfm/a7fHcB2MhdSty/gNchcoCjZ9z2ux223dFzfV05A2TOOmczBF8LnY5btEW9zb7cjrYhlCSeZ1T2ZsLUm1HXgAnJMXJABMTJcU6tJ/cS0OTLO4elWaJCX9GjHk7nlm/R6bH4YgZHCHMEMmgG4IiLpriu2RSZVPujZS0vjJPkNgIAoz+dP/PL/8ZdiCrNU8q33OYcsO7oSiZtcUiAWfhq9yVPOXxe6yQvI5Ps5sTynUYP++KcRiRSKK7h7m4D4hU2F7bwPSzU4nD8fGBVSY7b3JiwHsuhWuDABYR0iPiRqTcXCwlfcomnAewiGs9TvO8k1jT4EVaVuQudpLzMLSkiwwnt/eu8Z/x5Y+FftYGTghCSl4xiPA/y68A== Content-Type: multipart/alternative; boundary="_000_AC40F2B0ABBE494DAFBC42BB840D2A89nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a769d8e2-6329-4785-5fb0-08d7955727b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 22:56:25.6559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MRfOKozBC5CIyGKx/6T8f7K6mTMnskbK0ysmfsoMa1dPE7Z5zJ7YSSzEAqv6y55XLSCWO+P3FnCuTHH7XRjptw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB4091 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_05:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 clxscore=1015 spamscore=0 priorityscore=1501 suspectscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090191 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 23:10:49 -0000 --_000_AC40F2B0ABBE494DAFBC42BB840D2A89nbcunicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 1/9/20, 12:20 PM, "Add on behalf of Ted Lemon" on behalf of mellon@fugue.com> wrote: On Jan 9, 2020, at 11:43 AM, Alissa Cooper > wrote: I suspect a rev of the charter Tommy posted in December [1] to reflect comm= ents in that thread would be close enough to start the community-wide feedb= ack step of the chartering process, given the support expressed for it thus= far. [1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w I agree with this in a general sense, although figuring out how to update T= ommy=92s proposal based on the subsequent discussion might be challenging b= ecause there=92s been so much of it. I do not think Glenn Dean=92s proposal is a good place to start. It would = however be useful for Glenn to say what he would want changed in Tommy=92s = version of the charter. [GD] As I said in my other notes =96 Tommy=92s version is very similar in i= ts goals which is a very good sign. The main difference is how much and wh= at you front load the WG with constraints on where they start and how they = have to proceed. The areas that I would change would be to remove a few things: 1. I would remove the following since I think the getting into informing= clients of what is appropriate is both a can of worms, and gets into the r= ealm of telling the clients what to choose versus the clients pulling the i= nformation they want and then making their choice based on whatever logic t= hey have in the client. - inform clients about how to select appropriate encrypted and unencryp= ted resolvers for DNS queries in various network environments and use cases= . 2. Remove (below) the Adaptive DNS draft starting point because as it cu= rrently is Adaptive DNS goes beyond D&S and gets into interesting areas of = resolver behavior including the MUST requirement that DoH servers support u= biquitous DNS. That=92s more than D&S as I say is interesting but it=92s = far more than the WG should try to take on if it wants to be able to reason= ably deliver output. BTW =96 I=92m not saying don=92t discuss such things= . I am simply saying such things would better be done in another WG. The starting point for the group's work is Adaptive DNS (draft= -pauly-dprive-adaptive-dns-privacy), subject tothe working group's design c= hoices. 1. I would also do an edit to make sure it is not specific to DoH and Do= T and make it about any DNS. The current rev. mentions unencrypted DNS in s= ome places and focuses on DoH in others. Both Encrypted DNS and even tradit= ional DNS/53 since if the group were to produce a better way of discovering= and selecting DNS resolvers there isn=92t any reason to limit its use to e= ncrypted DNS. Network environments like enterprises that may choose to use = DNS/53 could benefit from it. 1. I continue to advocate for changing the name to not be ADD. Too much = baggage comes with it. I continue to propose the simpler DNS Discovery and= Selection or DNS-DS On 1/9/20, 12:20 PM, "Add on behalf of Ted Lemon" on behalf of mellon@fugue.com> wrote: The problem with Glenn=92s proposal is that it largely ignores what has bee= n discussed thus far, and leaves things wide open rather than tightly scope= d, which has caused problems in the past. A DHCP option to configure DoH s= ervers would be in-scope for Glenn=92s charter, for example, and could be d= one without any discussion about how to establish or validate trust, which = I think would be an unfortunate outcome because there would be no point in = implementing it. [GD] While it would be in scope, it would be subject to the WG participants= discussing it and having to come to consensus on it. Any WG=92s missio= n is not to force any particular outcome =96 it=92s to bring the parties to= gether and to work through what is brought to the table in the form of draf= ts and comments and to hopefully develop consensus around harmonized propos= als. Any such proposal would also need to deal with both security and pri= vacy considerations in order to move forward. I=92m not saying I advocate for such things, or that anyone is going to put= forth a draft proposing doing it with basic existing DHCP, but I wouldn= =92t be surprised if such things do show up in deployments in the wild. = There may be value in having someone capture the issues around doing it so = that there is a thread or repository of knowledge that people can refer to = when considering doing such a thing. Finally, my intent was not to ignore what has been discussed thus far, or h= ave them disappear. I figured the existing ideas that have had some discus= sion on the ADD list would be seeds for more discussion. What=92s lacking = to pull those together in a useful way is an actual WG and drafts in that W= G to manage those comments. Here then is what those edits would look like: Adaptive DNS Discovery (ADD) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposed Working Group Charter Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. Discovering and selecting DNS Resolvers by DNS clients is then an essential step in clients selecting the resolver to use in this more diverse environm= ent where regardless of if the choice is an encrypted DNS resolver supporting DoH or DoT or legacy unencrypted DNS/53 recursive resolution. Clients that want to adopt encrypted DNS protocols need to determine which DNS servers support encrypted transports, and which server to use in which context if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. For instance, the use of DNS servers associated with a particular content or domain when accessing that content or domain may be beneficial from a privacy perspective. Network operators that start offering DNS encryption on their servers need a way to indicate this support to clients. Beyond support for encrypted DNS, local networks may also have policy about the use of DNS to non-local DNS servers. Communicating such network policy to clients would allow clients to make more informed decisions about which DNS servers to use. The Adaptive DNS Discovery (ADD) working group will define mechanisms and protocols to: - allow clients to discover encrypted DNS resolvers, such as DoH servers, that are available publicly or on local networks; - allow network providers to communicate DNS policy to clients, including information about locally-accessible names; The mechanisms defined by this working group will consider several deployment scenarios, including public networks, home and mobile networks, enterprise networks, captive networks, and school networks. Any mechanisms that specify interactions between clients and servers must provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols. It will also work with capport to ensure that solutions are applicable to captive networks. -glenn deen --_000_AC40F2B0ABBE494DAFBC42BB840D2A89nbcunicom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

On 1/9/20, 12:20 PM, "Add on behalf of Ted Lemon" <add-bounces@ietf.org on behalf of mellon@fugue.com> wrote:

 

On Jan 9, 2020, at 11:43 AM, Alissa Cooper <alissa@cooperw.in> wrote:

I suspect a rev of the charter Tommy posted in December [1] to reflect c= omments in that thread would be close enough to start the community-wide fe= edback step of the chartering process, given the support expressed for it thus far.

 

[1= ] https://mailarchive.ietf.org/arc= h/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w

 

I agree with this in a general sense, although figuring out how to update T= ommy=92s proposal based on the subsequent discussion might be challenging b= ecause there=92s been so much of it.

 

I do not think Glenn Dean=92s proposal is a good place to start.  It w= ould however be useful for Glenn to say what he would want changed in Tommy= =92s version of the charter.

 

 

[GD] As I said in my other notes =96 = Tommy=92s version is very similar in its goals which is a very good sign. &= nbsp;The main difference is how much and what you front load the WG with co= nstraints on where they start and how they have to proceed.

 

The areas that I would change would b= e to remove a few things:

 

  1. I would remove the following since I = think the getting into informing clients of what is appropriate is both a c= an of worms, and gets into the realm of telling the clients what to choose = versus the clients pulling the information they want and then making their choice based on whatever logic they have i= n the client.

 

 &nb= sp;  - inform clients about how to select appropriate encrypted and un= encrypted resolvers for DNS queries in various network environments and use= cases.

 

2.    R= emove (below) the Adaptive DNS draft starting point because as it currently= is Adaptive DNS goes beyond D&S and gets into interesting areas of res= olver behavior including the MUST requirement that DoH servers support ubiquitous DNS.   That=92s more than D&= amp;S as I say is interesting but it=92s far more than the WG should try to= take on if it wants to be able to reasonably deliver output.   B= TW =96 I=92m not saying don=92t discuss such things. I am simply saying such things would better be done in another WG.

 

 &nb= sp;           The startin= g point for the group's work is Adaptive DNS (draft-pauly-dprive-adaptive-d= ns-privacy), subject tothe working group's design choices.

 

  1. I would also do an edit to make sure = it is not specific to DoH and DoT and make it about any DNS. The current re= v. mentions unencrypted DNS in some places and focuses on DoH in others. Bo= th Encrypted DNS and even traditional DNS/53 since if the group were to produce a better way of discovering and = selecting DNS resolvers there isn=92t any reason to limit its use to encryp= ted DNS. Network environments like enterprises that may choose to use DNS/5= 3 could benefit from it.    

 

  1. I continue to advocate for changing t= he name to not be ADD. Too much baggage comes with it.  I continue to = propose the simpler DNS Discovery and Selection or DNS-DS

 

 

On 1/9/20, 12:20 PM, "Add on behalf of Ted Lemon" <add-bounces@ietf.org on behalf of mellon@fugue.com> wrote:

 

The problem with Glenn=92s proposal is that it largely ignores what has bee= n discussed thus far, and leaves things wide open rather than tightly scope= d, which has caused problems in the past.  A DHCP option to configure = DoH servers would be in-scope for Glenn=92s charter, for example, and could be done without any discussion about how t= o establish or validate trust, which I think would be an unfortunate outcom= e because there would be no point in implementing it.

 

[GD] While it would be in scope, it w= ould be subject to the WG participants discussing it and having to come to = consensus on it.     Any WG=92s mission is not to force= any particular outcome =96 it=92s to bring the parties together and to work through what is brought to the table in the form of drafts and= comments and to hopefully develop consensus around harmonized proposals.&n= bsp;  Any such proposal would also need to deal with both security and= privacy considerations in order to move forward.  

 

I=92m not saying I advocate for such = things, or that anyone is going to put forth a draft proposing doing it wit= h basic  existing DHCP, but I wouldn=92t be surprised if such things d= o show up in deployments in the wild.    There may be value in having someone capture the issues around doing it so that = there is a thread or repository of knowledge that people can refer to when = considering doing such a thing.

 

Finally, my intent was not to ignore = what has been discussed thus far, or have them disappear.  I figured t= he existing ideas that have had some discussion on the ADD list would be se= eds for more discussion.  What=92s lacking to pull those together in a useful way is an actual WG and drafts in that = WG to manage those comments.  

 

Here then is what those edits would l= ook like:

 

Adaptive DNS Discovery (ADD)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Proposed Working Group Charter
 
Sending DNS messages over encrypted transports, as defined in D=
NS over
TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provi=
des
benefits to the security and privacy of DNS data. Clients, such=
 as
applications and host operating systems, have started adopting =
these
protocols to provide these user benefits.
 
Discovering and selecting DNS Resolvers by DNS clients is then =
an essential
step in clients selecting the resolver to use in this more dive=
rse environment
where regardless of if the choice is an encrypted DNS resolver =
supporting 
DoH or DoT or legacy unencrypted DNS/53 recursive resolution. <=
/span>
 
Clients that want to adopt encrypted DNS protocols need to dete=
rmine
which DNS servers support encrypted transports, and which serve=
r to
use in which context if multiple servers are available. These d=
ecisions
can vary based on the network environment, and also based on th=
e content
and purpose of the client queries. For instance, the use of DNS=
 servers
associated with a particular content or domain when accessing t=
hat content
or domain may be beneficial from a privacy perspective.<=
/pre>

 


Network operators that start offering DNS encryption on their s=
ervers


need a way to indicate this support to clients. Beyond support =
for


encrypted DNS, local networks may also have policy about the us=
e of DNS


to non-local DNS servers. Communicating such network policy to =
clients


would allow clients to make more informed decisions about which=
 DNS


servers to use.


 


The Adaptive DNS Discovery (ADD) working group will define mech=
anisms and


protocols to:


 


- allow clients to discover encrypted DNS resolvers, such as Do=
H


servers, that are available publicly or on local networks;


 


- allow network providers to communicate DNS policy to clients,=



including information about locally-accessible names;

 


 


The mechanisms defined by this working group will consider seve=
ral


deployment scenarios, including public networks, home and mobil=
e


networks, enterprise networks, captive networks, and school net=
works.


 


Any mechanisms that specify interactions between clients and


servers must provide the security properties expected of IETF


protocols, e.g., confidentiality protection, integrity protecti=
on,


and authentication with strong work factor.


 


This working group will coordinate with dnsop, doh, and dprive =
for any


changes required in DNS protocols. It will also work with cappo=
rt to


ensure that solutions are applicable to captive networks.



 



 



-glenn deen

 

 

--_000_AC40F2B0ABBE494DAFBC42BB840D2A89nbcunicom_-- From nobody Thu Jan 9 15:48:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF56B12003E for ; Thu, 9 Jan 2020 15:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 aY3hDM5iGgLQ for ; Thu, 9 Jan 2020 15:48:20 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 C45C2120072 for ; Thu, 9 Jan 2020 15:48:20 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id t17so297953ilm.13 for ; Thu, 09 Jan 2020 15:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=58cr6tkr5mLyZk0/ne4IiV7wAKSNzdmv1hXyuqHS5zg=; b=u1NcQMaQfbhfOCJhsSRIEUmgtL7nDISoZOPqL4y/CGUphYxNgDTJQN51zAgKYjNwI4 RxPIrcUJM841+9lqb4+QL7eTXbZWt0lMVJhTKig1mTH+qN5Awc5AmkwMHfasOHcO3K0B LvixfiO1EZukUNPFI2IBjjjW7iF5dBi+cY/+C8YbPuoiNFwTbG5GQj6/nR9/HCvLDamU Yre5eXpBvpK3eMGjGDxHPfmikBRsrnNdHBSqQ4kzoJUsdPyJLqDFhSOYxT0xIa3fp9KU 3ixxpOu6LujJflNdpL7m1Yb3425lnDSBmiMK0JwNijpGkFyhd8G2yjBk+i/WXlpWA2CF hKcA== 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=58cr6tkr5mLyZk0/ne4IiV7wAKSNzdmv1hXyuqHS5zg=; b=jGhkvRUn49Mp77/FwoNtUTcgfShH7JfiPc+cXmkDA6Ers6lvod2UL8nM5gCdO65DFP bRnHgwTo2WUvwspz8/ZmtNZkryagUT03/v5sFKzJHBLdRXA9w0DBIKhGW2EzFq4BrqBZ TRQlje7YhmjLmZI6NjAxVEPklO6GsCp2j0YBNBioKmruL/ncFYIL97shBmofe1377lUG 3FEg507w7n8O7/6OgieuRCXqNKmOtGdB5OOmEjFWFQeldGnnFWBqT8K6PMpcPpOzbX72 1ROHhrKPmqRh+Y9M+r7mIB1Y0daFU+/3miZCFjI7MIhyO+vbPVWZKcGwQor1xx9c5yU3 eq0Q== X-Gm-Message-State: APjAAAVyc6+fd5LBHYAM4BZkjMKratXhhVpZQxDt2VnA4/mrI2GuL4z0 62LxAfh+Pz7AJDavsxdvKVWxcjy2Nnicm8bpHfk= X-Google-Smtp-Source: APXvYqxQfKpcSFdSSBhOjVgFPUIRDFsrD7RdEDOcTWH1PsnSNrcL/1FX4ttD4odnxRnkvX39x1jY6clQL5M5+jC+FiI= X-Received: by 2002:a92:498d:: with SMTP id k13mr171341ilg.254.1578613700119; Thu, 09 Jan 2020 15:48:20 -0800 (PST) MIME-Version: 1.0 References: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> In-Reply-To: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> From: Rob Sayre Date: Thu, 9 Jan 2020 15:48:09 -0800 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Tommy Pauly , Vittorio Bertola , ADD Mailing list , Mirja Kuehlewind , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000d55234059bbda465" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 23:48:23 -0000 --000000000000d55234059bbda465 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 3:05 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > On 1/9/20, 12:44 PM, "Rob Sayre" wrote: > > I'm not sure what Glenn means by "resolver behavior". Does that mean > client behavior? I looked at the draft again and didn't find any > requirements on servers that would be incompatible with existing > implementations, though of course there are some new capabilities around > discovery and selection. > > > > [GD] I was referring to the section on server behavior in section 4 of th= e > draft. > https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01 > > > > My objection being that it=E2=80=99s out of scope for a WG focused on D&S= , it is > an interesting discussion but I think fits into DPRIV. > I see. Some parts of Section 4 are straightforwardly about discovery and selection (for example: "Clients can use this list to optimize lookups for common names."). Perhaps the issue is Oblivious DoH? It seems to me that support for that could be an important part of resolver selection for some clients, and it will change the DNS ecosystem. However, it also seems to me that it's not a protocol that can be prevented now that DoH is deployed. thanks, Rob --000000000000d55234059bbda465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 9, 2020 at 3:05 PM Deen, Glen= n (NBCUniversal) <Glenn.Deen@nb= cuni.com> wrote:

On 1/9/20, 12:44 PM, &qu= ot;Rob Sayre" <sayrer@gmail.com> wrote:

I'm not sure what Gl= enn means by "resolver behavior". Does that mean client behavior?= I looked at the draft again and didn't find any requirements on server= s that would be incompatible with existing implementations, though of course there are some new capabilities around discovery and sele= ction.

=C2=A0<= u>

[GD] I was ref= erring to the section on server behavior in section 4 of the draft.=C2=A0 https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01<= u>

=C2=A0<= u>

My objection b= eing that it=E2=80=99s out of scope for a WG focused on D&S, it is an i= nteresting discussion but I think fits into DPRIV.


I see. Some parts of S= ection 4 are straightforwardly about discovery and selection (for example: = "Clients can use this list to optimize lookups for common names."= ).

Perhaps the issue is Oblivious DoH? It seems to= me that support for that could be an important part of resolver selection = for some clients, and it will change the DNS ecosystem. However, it also se= ems to me that it's not a protocol that can be prevented now that DoH i= s deployed.

thanks,
Rob

--000000000000d55234059bbda465-- From nobody Thu Jan 9 15:58:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04F12022E for ; Thu, 9 Jan 2020 15:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 tqCX1xRsakHJ for ; Thu, 9 Jan 2020 15:58:28 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 6CE0C12003E for ; Thu, 9 Jan 2020 15:58:28 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id a15so272336otf.1 for ; Thu, 09 Jan 2020 15:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=opnVDNmtsgalGEyMoXvYx/ztw59Zzwhn7V5ckCZzEXU=; b=cd7rkpjJLwovZLAZTk5j9U+B7JbQEIqc8jQksP8GO3H3YLrs3EAe+K3PMrkClMqlEB g2DtC4lpiZJH/VYFGu+hwZx19hP0vDWH7H/78PUbDXML9zU0RWWAi7KdL+rOgUnRMxmI Pu0ueBAlCQsLkJwLgYEYNpIrZfH9+gjFjs189SOvRgJxLWxmvZxRWVJYWYR98LYxIOkf ZygShF9huH90ZkWwaOHmab7vT77NNXKbOn7HGwSQkp9jPJro5jPhkzeM2+J/jk4nsWka JPqAPC2HqHSKJ5x7tAHRNTK4Ff30IhO54sP0Gp+GYiQRiusdKuP0u7My3rIzC75shV2E QcyA== 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=opnVDNmtsgalGEyMoXvYx/ztw59Zzwhn7V5ckCZzEXU=; b=ZU0j0EuIRPglo3+70G2ecDCquPIgPwyuRnmC4BRiea7zsr6Sqw4xyZPUdEc+qSbxpb Kqw27Bp1NkUBHhpweyJyEvoV7ka3yXLRKkSmasLTy+60q6c+Xd4kY69plrp7Nj+MPQ3S YR2pqmk+qAE2c0WEP5jfuhek5jc+Sgx0OIEux6F0zComOefl1bumLHIJxnCKiK0JvkOb 7N5ofpO61A4tkla9UgF6ppgx3AsTrz7Nq0w+NlNBthiu9bmML+WWDFZMMicvtI8N8xgT k887NjwV3F9WaAMaW0xwGAWCEjQkoB7jRyFmUei/NLaKlZkqUxU9cY3sDMc8UXGolKPD 3jeQ== X-Gm-Message-State: APjAAAWTOFTByfwybd18dA/3kfA8ga68XhN79FH3eVrVP7eL8gZGrEbQ lQk6qXE4Z7iAVbcuSYihT2AlnwqWIXcfnvh1hfo= X-Google-Smtp-Source: APXvYqwKOsb7Xm20YnLFhmXDThz0gahFQedSL5cPoZcD71BMLh3JXd4NO4oVKZYfJ3Is/PCiAFOpaAGt5AcIVYNyHbc= X-Received: by 2002:a05:6830:1e37:: with SMTP id t23mr373143otr.16.1578614307796; Thu, 09 Jan 2020 15:58:27 -0800 (PST) MIME-Version: 1.0 References: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> In-Reply-To: From: Glenn Deen Date: Thu, 9 Jan 2020 15:58:17 -0800 Message-ID: To: Rob Sayre Cc: ADD Mailing list , "Deen, Glenn (NBCUniversal)" , Mirja Kuehlewind , Stephen Farrell , Tommy Pauly , Vittorio Bertola Content-Type: multipart/alternative; boundary="0000000000000dbbf1059bbdc952" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 09 Jan 2020 23:58:32 -0000 --0000000000000dbbf1059bbdc952 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 3:48 PM Rob Sayre wrote: > On Thu, Jan 9, 2020 at 3:05 PM Deen, Glenn (NBCUniversal) < > Glenn.Deen@nbcuni.com> wrote: > >> On 1/9/20, 12:44 PM, "Rob Sayre" wrote: >> >> I'm not sure what Glenn means by "resolver behavior". Does that mean >> client behavior? I looked at the draft again and didn't find any >> requirements on servers that would be incompatible with existing >> implementations, though of course there are some new capabilities around >> discovery and selection. >> >> >> >> [GD] I was referring to the section on server behavior in section 4 of >> the draft. >> https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01 >> >> >> >> My objection being that it=E2=80=99s out of scope for a WG focused on D&= S, it is >> an interesting discussion but I think fits into DPRIV. >> > > I see. Some parts of Section 4 are straightforwardly about discovery and > selection (for example: "Clients can use this list to optimize lookups fo= r > common names."). > > Perhaps the issue is Oblivious DoH? It seems to me that support for that > could be an important part of resolver selection for some clients, and it > will change the DNS ecosystem. However, it also seems to me that it's not= a > protocol that can be prevented now that DoH is deployed. > My objection here is about adding it to a wg focused on D&S by clients; isn=E2=80=99t helpful to keeping the D&S focused and on track. Sure there maybe information to convey to clients that they can use in their selection choice. That would be in scope. It=E2=80=99s the part w= here it gets into specifying the behavior of the resolvers that gets to be too far from D&S. This new potential group we are discussing isn=E2=80=99t a broad group abou= t dns privacy , we already have Dpriv for that stuff. -glenn deen --0000000000000dbbf1059bbdc952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 9, 2020 at 3:48 PM Rob Sayre <sayrer@gmail.com> wrote:
On Thu, Jan 9, 2020 at 3:05 PM Deen,= Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:

On 1/9/20, 12:44 PM, &qu= ot;Rob Sayre" <sayrer@gmail.com> wrote:

I'm not sure what Gl= enn means by "resolver behavior". Does that mean client behavior?= I looked at the draft again and didn't find any requirements on server= s that would be incompatible with existing implementations, though of course there are some new capabilities around discovery and sele= ction.

=C2=A0

[GD] I was ref= erring to the section on server behavior in section 4 of the draft.=C2=A0 https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01<= u style=3D"font-family:Helvetica">

=C2=A0

My objection b= eing that it=E2=80=99s out of scope for a WG focused on D&S, it is an i= nteresting discussion but I think fits into DPRIV.


I see. Some parts of S= ection 4 are straightforwardly about discovery and selection (for example: = "Clients can use this list to optimize lookups for common names."= ).

Perhaps the issue is Oblivious DoH? It seems to= me that support for that could be an important part of resolver selection = for some clients, and it will change the DNS ecosystem. However, it also se= ems to me that it's not a protocol that can be prevented now that DoH i= s deployed.

=

My objection here is ab= out adding it to a wg focused on D&S by clients; =C2=A0isn=E2=80=99t he= lpful to keeping the D&S focused and on track.=C2=A0

Sure there maybe information to convey to = clients that they can use in their selection choice. =C2=A0 That would be i= n scope. =C2=A0 It=E2=80=99s the part where it gets into specifying the beh= avior of the resolvers that gets to be too far from D&S.=C2=A0

This new potential group we are = discussing isn=E2=80=99t a broad group about dns privacy , we already have = Dpriv for that stuff.=C2=A0

-glenn deen=C2=A0
--0000000000000dbbf1059bbdc952-- From nobody Thu Jan 9 16:03:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835F612022E for ; Thu, 9 Jan 2020 16:03:10 -0800 (PST) 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=unavailable 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 pf3XsQA7TC75 for ; Thu, 9 Jan 2020 16:03:06 -0800 (PST) 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 1B52D12012A for ; Thu, 9 Jan 2020 16:03:06 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id z8so136069ioh.0 for ; Thu, 09 Jan 2020 16:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kf3MPCvA6RI/eHaJpzqlDk8URS6wBfzYkcIPBaTiojY=; b=NEckJC1IVlo+tYOHtfWbMrcGVpDfh2TlxLmJJKMjidrDxFdmwrObjQOkoMzs8C3yBr mQTbe/hRhWpZfQR/jNRjqQrhVHIxvmR1CL+YNUQl2Uk7jKJv3R0hxYLFPg5VqNu9M5y5 ujXPidybUJh9aEwH/+xSC0Bmn/lNZ4YBC38tgmUso3a9CkoxMSjpxxbMUu1ZwIUqTxRW mke0APF+kMxssKbTqjj7itLtqaGS5BTDyXNe7SDubw2PBWjt8S2Y8repaVNk4HVgFhtO +yN41dEWLfxAuj4uD4cvRSlFngTLl+D+ia0xQ25msZWStOM1A0uniulMwOnCY7ibHlSC YKBA== 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=Kf3MPCvA6RI/eHaJpzqlDk8URS6wBfzYkcIPBaTiojY=; b=PAEPrtX8u/xvOWCfwvdHRn81eTRf2VatVTP/eMBi6fgXAJ+qgyuNXN8ni4yEWm9dEM bAPLHKOa16DmcVnkPLKHDOOXJc4dn7VZKZ87PdmuvXXHG/r6ozmlvdqEPRusCtMtu+WW lcGvh7KkyDG70ucLdiq148LryM8N+0srCfIPvalTZp5Tm54+LzyxwhhHnfxY8huyxVgG zGZERvWj08WkkHBoFzmF15E5j2q6ZNh+U1tmlfNeb2zl5v+Cs7qPWXQLXTSoY7WW4jmQ EAGFFrVDswrABwgPWt0Rbu5HSrJSXtZqc7IwRVTyNifrMAt8hZXMB5+1VzfYBfzPAApe LY7g== X-Gm-Message-State: APjAAAWVmv722ynJIpnUeOWCFSX8sFlhcbbTd3bra7s0YRPV0DhgTtWW wjFhcFCqnG65zsF8WfKbSCcdpBZteeOxZw9Cdnk= X-Google-Smtp-Source: APXvYqx5b8gmbZ8SRfrYoGmbLQQzdRN+HXOoW9Nob9/zdpw+p06fMZxA1waLgVPbllLKm6DoVgwkTZZtSOFLcSyBDcY= X-Received: by 2002:a6b:fc0c:: with SMTP id r12mr86390ioh.189.1578614585337; Thu, 09 Jan 2020 16:03:05 -0800 (PST) MIME-Version: 1.0 References: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> In-Reply-To: From: Rob Sayre Date: Thu, 9 Jan 2020 16:02:53 -0800 Message-ID: To: Glenn Deen Cc: ADD Mailing list , "Deen, Glenn (NBCUniversal)" , Mirja Kuehlewind , Stephen Farrell , Tommy Pauly , Vittorio Bertola Content-Type: multipart/alternative; boundary="00000000000098ad6c059bbdd9fc" Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 00:03:10 -0000 --00000000000098ad6c059bbdd9fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 3:58 PM Glenn Deen wrote: > > > On Thu, Jan 9, 2020 at 3:48 PM Rob Sayre wrote: > >> On Thu, Jan 9, 2020 at 3:05 PM Deen, Glenn (NBCUniversal) < >> Glenn.Deen@nbcuni.com> wrote: >> >>> On 1/9/20, 12:44 PM, "Rob Sayre" wrote: >>> >>> I'm not sure what Glenn means by "resolver behavior". Does that mean >>> client behavior? I looked at the draft again and didn't find any >>> requirements on servers that would be incompatible with existing >>> implementations, though of course there are some new capabilities aroun= d >>> discovery and selection. >>> >>> >>> >>> [GD] I was referring to the section on server behavior in section 4 of >>> the draft. >>> https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01 >>> >>> >>> >>> My objection being that it=E2=80=99s out of scope for a WG focused on D= &S, it is >>> an interesting discussion but I think fits into DPRIV. >>> >> >> I see. Some parts of Section 4 are straightforwardly about discovery and >> selection (for example: "Clients can use this list to optimize lookups f= or >> common names."). >> >> Perhaps the issue is Oblivious DoH? It seems to me that support for that >> could be an important part of resolver selection for some clients, and i= t >> will change the DNS ecosystem. However, it also seems to me that it's no= t a >> protocol that can be prevented now that DoH is deployed. >> > > > My objection here is about adding it to a wg focused on D&S by clients; > isn=E2=80=99t helpful to keeping the D&S focused and on track. > > Sure there maybe information to convey to clients that they can use in > their selection choice. That would be in scope. It=E2=80=99s the part= where it > gets into specifying the behavior of the resolvers that gets to be too fa= r > from D&S. > > This new potential group we are discussing isn=E2=80=99t a broad group ab= out dns > privacy , we already have Dpriv for that stuff. > Only the charter you proposed is that narrow, and I agree with other messages that say it's too narrow. The other two proposals, from Tommy Pauly and Ben Schwartz, are more broad. thanks, Rob --00000000000098ad6c059bbdd9fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 3:58 PM Glenn = Deen <rgd.ietf@gmail.com> w= rote:

<= /div>

On Thu, Jan 9, 2020 at 3:48 PM Rob Sayre <sayrer@gmail.com> wrote:
On Thu, Jan 9, 2020 at 3:05 PM Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com&= gt; wrote:

On 1/9/20, 12:44 PM, &qu= ot;Rob Sayre" <sayrer@gmail.com> wrote:

I'm not sure what Gl= enn means by "resolver behavior". Does that mean client behavior?= I looked at the draft again and didn't find any requirements on server= s that would be incompatible with existing implementations, though of course there are some new capabilities around discovery and sele= ction.

=C2=A0

[GD] I was ref= erring to the section on server behavior in section 4 of the draft.=C2=A0 https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01<= u style=3D"font-family:Helvetica">

=C2=A0

My objection b= eing that it=E2=80=99s out of scope for a WG focused on D&S, it is an i= nteresting discussion but I think fits into DPRIV.


I see. Some parts of S= ection 4 are straightforwardly about discovery and selection (for example: = "Clients can use this list to optimize lookups for common names."= ).

Perhaps the issue is Oblivious DoH? It seems to= me that support for that could be an important part of resolver selection = for some clients, and it will change the DNS ecosystem. However, it also se= ems to me that it's not a protocol that can be prevented now that DoH i= s deployed.

=

My objection here is ab= out adding it to a wg focused on D&S by clients; =C2=A0isn=E2=80=99t he= lpful to keeping the D&S focused and on track.=C2=A0

Sure there maybe information to convey to = clients that they can use in their selection choice. =C2=A0 That would be i= n scope. =C2=A0 It=E2=80=99s the part where it gets into specifying the beh= avior of the resolvers that gets to be too far from D&S.=C2=A0

This new potential group we are = discussing isn=E2=80=99t a broad group about dns privacy , we already have = Dpriv for that stuff.=C2=A0

Only the charter you proposed is that narrow, and I agree with other= messages that say it's too narrow. The other two proposals, from Tommy= Pauly and=C2=A0Ben Schwartz, are more broad.

than= ks,
Rob=C2=A0
--00000000000098ad6c059bbdd9fc-- From nobody Thu Jan 9 17:01:50 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5473312022E for ; Thu, 9 Jan 2020 17:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lueeMVzW9bpl for ; Thu, 9 Jan 2020 17:01:46 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100071.outbound.protection.outlook.com [40.107.10.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 37294120131 for ; Thu, 9 Jan 2020 17:01:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oJJdjmajQR39nik404QmJqW1CCp0X+z7L2YN1IwaiOwxusjkmlE5IP7ALbmhNc3t09TcYiwt6Hi5j9w6phPYXks7IcTIAIwrR1/TeCc3fHAJDq/2rqoj1sX55GWMpGo/+ms0Ltf1Hz8RtN+hhDRF0i110CJ2C/V99N7n9gLIT0iRtLlo6F0Yyv7Vho+YDToShGrUJwXPXr/cFbxXRf96v9ODEFH9boRnKDo8JQmAlS5EQ4OmSgS1TZPI/XvZYWgpIlWzb+Ih5M35WdLaxrjwLYYXy5gqSN0t7S3a2LQhcKmr5OANjWoTbkm7OSYKeRp1FEW1JIJBZ9cT0MQcr9txJg== 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=249IrfyiT7G4/t9lzmQJ9Pev+zsj6b1udDRGsryt1w4=; b=dqK7lIpX6xQQ8mq/dvuve2/z3z+GuxHRfOLrxGu0zSzlBgGjDOSxg+FQkctynSBAEbctZLTIv9aD4DQIMFZaBdOvyz/PFzgvr73CHM6YxjJpK7J9wvahHYpHwuaM5WY2E614xgpWlKYxyzL291E6FoxgVd6oJzxqlQpuxpom6HnjauVy2qCWxplFFfAKBrEWKvGKQB14v7q6kHRcOBHteEKBRwJQE9qQaWcA7n6TSs/Zz54g1FAfEun5kg+L7/XyLx5fHylGYMrQvF2/Alw3i1mAjQMQuhynKrYfBgB185MjgYxNVsnP8Gk62ALkpmg2nfhKSkdABu0NtaAldV/YGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=249IrfyiT7G4/t9lzmQJ9Pev+zsj6b1udDRGsryt1w4=; b=VftlAA5XDIF5NFh2UyDsJq73JCS4TYv68y0g6HAUdi/9dwcHvQGfAoytJwZLvsLcKDolUxOd6vAz2ZACpHzoRJg/cdjyhiVplYPpfB4pnZ/FbdF1iNwn2mqr5HsndELn3sGC088JXgKUB3W2o1wDNGnwO0yKQECxXg8py2WCSS4= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1230.GBRP265.PROD.OUTLOOK.COM (20.176.141.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Fri, 10 Jan 2020 01:01:34 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.011; Fri, 10 Jan 2020 01:01:33 +0000 From: Andrew Campling To: Rob Sayre CC: "STARK, BARBARA H" , Ted Lemon , ADD Mailing list Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxziFLlI6yeKg7kavCe4wN7Y8zafi6hyggAAFuYCAACJHgA== Date: Fri, 10 Jan 2020 01:01:33 +0000 Message-ID: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> 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=andrew.campling@419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76820570-8452-4bd0-711c-08d79568a2f9 x-ms-traffictypediagnostic: LO2P265MB1230: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39830400003)(136003)(346002)(396003)(51444003)(189003)(199004)(66476007)(66946007)(6506007)(2906002)(8936002)(44832011)(66556008)(66446008)(71200400001)(76116006)(9686003)(64756008)(52536014)(7696005)(5660300002)(81156014)(508600001)(81166006)(186003)(86362001)(8676002)(316002)(55016002)(4326008)(6916009)(66574012)(54906003)(33656002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1230; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QdJLwNMA3ndl+P5Q76beK/Us6Ba4B3hDALZpKSqNppm82++m1txBdmXB1qRsTyf4aGFfTSzVJ3MNFQmFor0iS8jDaSPCKTrdza8KOuXrW+YtDhTFR4EM3Y807cbKFiJK7Yn5T9rUXN1Pf50YlfN2QAAfwcyXzHs7vODt20Xn5vAkRntSHILtMiOBytAUsQKSzcD/4zJ6QCebaAToxn7/5vgKV0FrHZxXW5k3fnmpDimduAzIc4Epzia/m2mB9lpZQhfY4cBS7NYdY46I6EKRhbe8pRvUOIiR5uZkonHuTVdJVlEVMn1Ln+IGhcA3DrxcyiNi0JnPplhY3yJ1ISf9XpmDY9fEThVQXcvJW8nHXs6KZjYHAXZInikQ4wGYIWT6lwtOcWZVX/gs5d3bojRxWEh44/37Ov3TlnY3851FvBYWs7OyyMJAIsL3dP3r4HRfHExYSBomZr4lQlihFciA+xkZPhcrHLp/QrBvXfMo6jQCO9+L0hELY7edUzS2KIVU6D0XrG7BKwXmdrmKpF1i/w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB05738C8BCFC37602B147E03EC2380LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 76820570-8452-4bd0-711c-08d79568a2f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 01:01:33.8289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w2+uQ5QbdpU7xGWB0b5QpadMBAyACJ06a8oppYQJXhItSO+z5S78ks7KekoKTy2x9gmrtRnjwN0vSensuVZZ4uGei6B3hnp88ne20DkAYQA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1230 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 01:01:48 -0000 --_000_LO2P265MB05738C8BCFC37602B147E03EC2380LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVGh1LCBKYW4gOSwgMjAyMCBSb2IgU2F5cmUgPHNheXJlckBnbWFpbC5jb20+IHdyb3RlOg0K DQo+IE9uIFRodSwgSmFuIDksIDIwMjAgQW5kcmV3IENhbXBsaW5nIDxhbmRyZXcuY2FtcGxpbmdA NDE5LmNvbnN1bHRpbmc8bWFpbHRvOmFuZHJldy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZz4+IHdy b3RlOg0KPj4gVGhpcyBzZWVtcyBlbnRpcmVseSBzZW5zaWJsZTogYXNzdW1pbmcgdGhhdCBubyBu ZXR3b3JrIGNhbiBldmVyIGJlIHRydXN0ZWQNCj4+IGlzIGNsZWFybHkgbm90IHNlbnNpYmxlLCBh cyBpcyBydWxpbmcgb3V0IGFuIG9wdGlvbiBhdCB0aGlzIHN0YWdlLiAgSXQgY291bGQNCj4+IHNp bXBsaWZ5IG1hbnkgdXNlIGNhc2VzIHRvIGRvIHNvIGFuZCB3b3VsZCBhdm9pZCBmb3JjaW5nIHRo ZSB1c2VyIHRvIHRydXN0DQo+PiBhbm90aGVyIGVudGl0eSB1bm5lY2Vzc2FyaWx5IHdoZW4gZG9p bmcgc28gaGFzIHRoZSBwb3RlbnRpYWwgdG8gaW50cm9kdWNlDQo+PiBhZGRpdGlvbmFsIHJpc2su DQoNCj4gIkVuZHBvaW50cyBzaG91bGQgbm90IGRlcGVuZCBvbiB0aGUgY29uZmlkZW50aWFsaXR5 IG9yIGludGVncml0eSBvZiB0aGUNCj4gY2FycmllcnMuIENhcnJpZXJzIG1heSBjaG9vc2UgdG8g cHJvdmlkZSBzb21lIGxldmVsIG9mIHByb3RlY3Rpb24sIGJ1dCB0aGlzDQo+IGlzIHNlY29uZGFy eSB0byB0aGUgcHJpbWFyeSByZXNwb25zaWJpbGl0eSBvZiB0aGUgZW5kIHVzZXJzIHRvIHByb3Rl Y3QNCj4gdGhlbXNlbHZlcy4iDQoNCj4gUkZDIDE5NTgNCj4gQXJjaGl0ZWN0dXJhbCBQcmluY2lw bGVzIG9mIHRoZSBJbnRlcm5ldA0KPiBKdW5lIDE5OTYNCg0KSSB0aGluayB0aGF0IHRoZSByZWZl cmVuY2UgdG8gUkZDIDE5NTggdW5kZXJzY29yZXMgdGhlIHByb2JsZW0gaW4gZGlmZmVyZW50IHBl cnNwZWN0aXZlcyBpbiB0aGlzIGRlYmF0ZTogdGhlIFJGQyBwcmUtZGF0ZXMgdGhlIHJpc2Ugb2Yg 4oCcc3VydmVpbGxhbmNlIGNhcGl0YWxpc23igJ07IHRoZSBtYW55IHByaXZhY3kgYnJlYWNoZXMg YnkgYXBwcyAoYW5kIOKAnHNtYXJ04oCdIGRldmljZXMpOyBhbmQgdGhlIGFjY2VsZXJhdGluZyBj b25zb2xpZGF0aW9uIGxlYWRpbmcgdG8gYSBmZXcgY29ycG9yYXRpb25zIGRvbWluYXRpbmcgbGFy Z2UgcGFydHMgb2YgdGhlIEludGVybmV0IHdpdGggdGhlIGNvbnNlcXVlbnQgbG9zcyBvZiByZXNp bGllbmNlLiAgVGhlcmVmb3JlLCB0aGUgaW1wbGljYXRpb24gb2YgUkZDIDE5NTggdGhhdCBpdCBp cyBiZXR0ZXIgdG8gcmVseSBvbiB0aGUgY29uZmlkZW50aWFsaXR5IG9yIGludGVncml0eSBvZiBl bmRwb2ludHMgcmF0aGVyIHRoYW4gY2FycmllcnMgaXMgYXQgYmVzdCBxdWVzdGlvbmFibGUgYW5k IGlzIGNlcnRhaW5seSBkYXRlZC4NCg0KQW5kcmV3DQoNCg== --_000_LO2P265MB05738C8BCFC37602B147E03EC2380LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUaHUsIEphbiA5LCAyMDIwIDxzcGFuIGxhbmc9IkVOLVVTIj5Sb2IgU2F5 cmUgJmx0O3NheXJlckBnbWFpbC5jb20mZ3Q7DQo8L3NwYW4+d3JvdGU6PGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE9u IFRodSwgSmFuIDksIDIwMjAgQW5kcmV3IENhbXBsaW5nICZsdDs8YSBocmVmPSJtYWlsdG86YW5k cmV3LmNhbXBsaW5nQDQxOS5jb25zdWx0aW5nIj5hbmRyZXcuY2FtcGxpbmdANDE5LmNvbnN1bHRp bmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBUaGlzIHNlZW1zIGVudGlyZWx5IHNlbnNp YmxlOiBhc3N1bWluZyB0aGF0IG5vIG5ldHdvcmsgY2FuIGV2ZXIgYmUgdHJ1c3RlZCA8YnI+DQom Z3Q7Jmd0OyBpcyBjbGVhcmx5IG5vdCBzZW5zaWJsZSwgYXMgaXMgcnVsaW5nIG91dCBhbiBvcHRp b24gYXQgdGhpcyBzdGFnZS4mbmJzcDsgSXQgY291bGQ8YnI+DQomZ3Q7Jmd0OyBzaW1wbGlmeSBt YW55IHVzZSBjYXNlcyB0byBkbyBzbyBhbmQgd291bGQgYXZvaWQgZm9yY2luZyB0aGUgdXNlciB0 byB0cnVzdCA8YnI+DQomZ3Q7Jmd0OyBhbm90aGVyIGVudGl0eSB1bm5lY2Vzc2FyaWx5IHdoZW4g ZG9pbmcgc28gaGFzIHRoZSBwb3RlbnRpYWwgdG8gaW50cm9kdWNlPGJyPg0KJmd0OyZndDsgYWRk aXRpb25hbCByaXNrLjxicj4NCjxicj4NCiZndDsgJnF1b3Q7RW5kcG9pbnRzIHNob3VsZCBub3Qg ZGVwZW5kIG9uIHRoZSBjb25maWRlbnRpYWxpdHkgb3IgaW50ZWdyaXR5IG9mIHRoZSA8YnI+DQom Z3Q7IGNhcnJpZXJzLiBDYXJyaWVycyBtYXkgY2hvb3NlIHRvIHByb3ZpZGUgc29tZSBsZXZlbCBv ZiBwcm90ZWN0aW9uLCBidXQgdGhpcyA8YnI+DQomZ3Q7IGlzIHNlY29uZGFyeSB0byB0aGUgcHJp bWFyeSByZXNwb25zaWJpbGl0eSBvZiB0aGUgZW5kIHVzZXJzIHRvIHByb3RlY3Q8YnI+DQomZ3Q7 IHRoZW1zZWx2ZXMuJnF1b3Q7PGJyPg0KPGJyPg0KJmd0OyBSRkMgMTk1ODxicj4NCiZndDsgQXJj aGl0ZWN0dXJhbCBQcmluY2lwbGVzIG9mIHRoZSBJbnRlcm5ldDxicj4NCiZndDsgSnVuZSAxOTk2 PGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IHRoZSByZWZlcmVuY2UgdG8gUkZDIDE5NTggdW5kZXJz Y29yZXMgdGhlIHByb2JsZW0gaW4gZGlmZmVyZW50IHBlcnNwZWN0aXZlcyBpbiB0aGlzIGRlYmF0 ZTogdGhlIFJGQyBwcmUtZGF0ZXMgdGhlIHJpc2Ugb2Yg4oCcc3VydmVpbGxhbmNlIGNhcGl0YWxp c23igJ07IHRoZSBtYW55IHByaXZhY3kgYnJlYWNoZXMgYnkgYXBwcyAoYW5kIOKAnHNtYXJ04oCd IGRldmljZXMpOyBhbmQgdGhlIGFjY2VsZXJhdGluZyBjb25zb2xpZGF0aW9uIGxlYWRpbmcNCiB0 byBhIGZldyBjb3Jwb3JhdGlvbnMgZG9taW5hdGluZyBsYXJnZSBwYXJ0cyBvZiB0aGUgSW50ZXJu ZXQgd2l0aCB0aGUgY29uc2VxdWVudCBsb3NzIG9mIHJlc2lsaWVuY2UuJm5ic3A7IFRoZXJlZm9y ZSwgdGhlIGltcGxpY2F0aW9uIG9mIFJGQyAxOTU4IHRoYXQgaXQgaXMgYmV0dGVyIHRvIHJlbHkg b24gdGhlIGNvbmZpZGVudGlhbGl0eSBvciBpbnRlZ3JpdHkgb2YgZW5kcG9pbnRzIHJhdGhlciB0 aGFuIGNhcnJpZXJzIGlzIGF0IGJlc3QgcXVlc3Rpb25hYmxlDQogYW5kIGlzIGNlcnRhaW5seSBk YXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFuZHJl dyA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_LO2P265MB05738C8BCFC37602B147E03EC2380LO2P265MB0573GBRP_-- From nobody Thu Jan 9 18:59:01 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DC91200C7 for ; Thu, 9 Jan 2020 18:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 bpoGefE0gb7L for ; Thu, 9 Jan 2020 18:58:57 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 2D9831200A3 for ; Thu, 9 Jan 2020 18:58:57 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id q8so388979pfh.7 for ; Thu, 09 Jan 2020 18:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=rwQiJ44sm+NzDKefjeR/VXDtn4Rb9tbt4xZoCQwOHB4=; b=fBAXXwr1uQFXVeAX8oPJQZxWPeDRGhdXqV7AhpyVjCUWcIJA3nH4s4CMpXaP3oq/oB 07CUUOhqJkPc1Gig8D7owHNL1MsEm03OUfiK6sEzcXciGovxPnoMR8GG6WHsRaha0VmA Sb3hF1LjTn6x8FlVBxy+MOqOq+MxgdIAqHSgsjTJIUVAkY2p1yOalcxdwDHVa2bT5RK6 oz1kew5o4MUviMhTWgvbT6Dn4/Y+ZgRpgW9nP9la9NU3wAc8DsmTgaAg8EDg5O/KycH2 KW15r9cuRliEd+/odi7mQ/zN2ZjRlWLHS5K+TeFAkF+Pul+HsnenOhxprG3c2O7OFwLh E/+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rwQiJ44sm+NzDKefjeR/VXDtn4Rb9tbt4xZoCQwOHB4=; b=PsCs1MBP5/XDzqxIjZEX5B1SP9pgWSVKv81KeN8DM+7btuK8pxkjvt7niA0TBjy7FW JpjkF5KJwbs9jXNK3E4yYw9K9f4L4KZXRYwzDA/PIjGYedtAVe2CLF2OSd5pVdhQEDY1 AqYWARq7xbtfmN7ol9kjqIxcUV/Vopyu92tR9SSUb/i8D+ImH6+FQc094PkYYOEJnyrF AMIoeCRD2TNCyxNRxGB5Mms7sQ60ZYEUHmK2eBj+Jdh9O8sPt2t+RHezMTEjZ2x+s0yQ Exo8JXDNEHSxLwoyxMfNbgxWpqSnfL42uTPAMgxjnwto36TwzqcOT/9F21DH7CIJ8z6Z KL8g== X-Gm-Message-State: APjAAAUJ1Ma+JjXPvCGi4KSVDpHFyXFGjK0NE67L+9nMNq/4bVjhKMP8 SuRrA2mAvSuw253uzaoDXHbiB5Eb/o4= X-Google-Smtp-Source: APXvYqxiM32a6F1eYU7Ut5DnvTqCDs4cJPbVPyk4BPhJCcB4mVJSDhCNVx5dsTUAKmSLwmPWcNo7dw== X-Received: by 2002:a63:4824:: with SMTP id v36mr1443653pga.343.1578625136319; Thu, 09 Jan 2020 18:58:56 -0800 (PST) Received: from [10.0.1.15] (cpe-107-184-135-4.socal.res.rr.com. [107.184.135.4]) by smtp.gmail.com with ESMTPSA id l21sm463004pff.100.2020.01.09.18.58.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jan 2020 18:58:55 -0800 (PST) From: "Glenn Deen" To: "ADD Mailing list" Date: Thu, 09 Jan 2020 18:58:54 -0800 X-Mailer: MailMate Trial (1.13.1r5671) Message-ID: In-Reply-To: References: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 02:59:00 -0000 On 9 Jan 2020, at 16:02, Rob Sayre wrote: > On Thu, Jan 9, 2020 at 3:58 PM Glenn Deen wrote: > >> >> >> On Thu, Jan 9, 2020 at 3:48 PM Rob Sayre wrote: >> >>> On Thu, Jan 9, 2020 at 3:05 PM Deen, Glenn (NBCUniversal) < >>> Glenn.Deen@nbcuni.com> wrote: >>> >>>> On 1/9/20, 12:44 PM, "Rob Sayre" wrote: >>>> >>>> I'm not sure what Glenn means by "resolver behavior". Does that >>>> mean >>>> client behavior? I looked at the draft again and didn't find any >>>> requirements on servers that would be incompatible with existing >>>> implementations, though of course there are some new capabilities >>>> around >>>> discovery and selection. >>>> >>>> >>>> >>>> [GD] I was referring to the section on server behavior in section 4 >>>> of >>>> the draft. >>>> https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01 >>>> >>>> >>>> >>>> My objection being that it’s out of scope for a WG focused on >>>> D&S, it is >>>> an interesting discussion but I think fits into DPRIV. >>>> >>> >>> I see. Some parts of Section 4 are straightforwardly about discovery >>> and >>> selection (for example: "Clients can use this list to optimize >>> lookups for >>> common names."). >>> >>> Perhaps the issue is Oblivious DoH? It seems to me that support for >>> that >>> could be an important part of resolver selection for some clients, >>> and it >>> will change the DNS ecosystem. However, it also seems to me that >>> it's not a >>> protocol that can be prevented now that DoH is deployed. >>> >> >> >> My objection here is about adding it to a wg focused on D&S by >> clients; >> isn’t helpful to keeping the D&S focused and on track. >> >> Sure there maybe information to convey to clients that they can use >> in >> their selection choice. That would be in scope. It’s the part >> where it >> gets into specifying the behavior of the resolvers that gets to be >> too far >> from D&S. >> >> This new potential group we are discussing isn’t a broad group >> about dns >> privacy , we already have Dpriv for that stuff. >> > > Only the charter you proposed is that narrow, and I agree with other > messages that say it's too narrow. The other two proposals, from Tommy > Pauly and Ben Schwartz, are more broad. That’s only somewhat true. All three focus on Discovery and Selection and even the one I proposed isn’t actually all that narrow since it defers to the WG and the ADs on where they need to go. Several comments on other proposals were concerned that they were opening up potential ratholes in their scope and already there is a whole thread going on here on ADD about what Trust means in a variety of contexts. A lot of that is because the Tommy Paul and Ben Schwartz proposals pulled in work beyond D&S and got into some discussion about resolver behavior and even policy via the drafts they mentioned. I’m not trying to curtailing any of these other discussions if people want to have them, but these ever ongoing postings on the ADD list have made very little progress to no progress toward resolution. Meanwhile we have Encrypted DNS deployments going on that have a critical need for scalable and practical discovery and selection. Pulling too much of that into the WG just adds to the quicksand the group needs to wade through. This whole area is such a broad topic area with no shortage of opinions, vision, or creativity - but at some point there is a need to do triage and get busy on highest priority need. My proposal was simply to break the log jam and get some real work started. If the ADs want to expand the WG scope at anytime either day 1 or day 100 of the WG’s life, as Ted L. pointed out earlier today, they can. All 3 proposals have good bones in my opinion, but I believe that the group will be primed for a higher chance of success if it can start by not trying to bite off too big a first bite. Whatever proposal is REV’d to produce a workable charter is fine. I even posted an edited version of the Pauly proposal a little earlier in response to Ted’s question of how I would edit that proposal. As for comments received: I’ll note that while there have been posts asserting that they’d like X or Y included, or in one case that they’d want to see DHCP excluded, there have also been a couple of posts in support of what I wrote and while some said it may not include everything they might want - they could live with it as a start. Being realistic, even limiting the work to Discovery and Selection gives the WG a lot of work to do, and hard work at that. We already have different D&S approaches being put on the table that when you dig into them are pretty far apart and the WG hasn’t even opened its door for draft submissions. Proposals range from the client getting the info from the network; from a domain communicating what the DNS services it recommends; clever applications of DNSSEC; some advocating applications of DHCP; and others. We also already have a client deployed in the wild that comes with the list built into the client which then combines that with the clients current DNS/53 settings to make its decision. So no shortage of approaches. This isn’t about being narrow so as to sidestep interesting proposals on how to evolve DNS, it is instead about taking a first bite that has an actual chance of progress in a reasonable time frame. Glenn From nobody Thu Jan 9 19:21:14 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3B1202A0 for ; Thu, 9 Jan 2020 19:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 4HSjaFlo7XCX for ; Thu, 9 Jan 2020 19:21:12 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 D69151200A3 for ; Thu, 9 Jan 2020 19:21:11 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id s15so671168iln.1 for ; Thu, 09 Jan 2020 19:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UZK25/i3qMfdfXoYp1hBPQU9C5IbvUfHuP5BmOY4ACs=; b=CktloZpg7ESPiScQ2uy9CIJJrK9Jg2RCYDKxP4r230oHSzlFwP72ZOQdktkJItc4vb TKU1rsubLCFeWrNccVG7O3FMrGMLBaIyfEoh0dz0UzTmGj4kWRiPjsIfVL23FpG50vSR tflU5UxRWwgTlNTc2QbJV0qLh3bFW3lEExi2fR4seYbqGvNHX/P2g8+38mvqSBqfvBgp Fo2o0kcsyWRcoljkSbFMAYMRHEdjVcUXu162qtTxY4VGIcKCqrEwF8up8NcrATsZuFkI ockNqlb90bWPxdyKiFH0vj4GjjVzf6ebYt7/oIOq76uChe03HvqHnjSu6CddztBIKYec jhbA== 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=UZK25/i3qMfdfXoYp1hBPQU9C5IbvUfHuP5BmOY4ACs=; b=YAPbQdusMSqxs8lV8mZA+El+XwYkvz4zboM6V+sRZSSq2g0DSXEtxpuCKx4AtHUsAr RsVJY1KYfODv0Wko8yuyHq911jMLw7x9jxkUzg3F9EV1fAaRXbka1jiv4ND3ArCdZKIg 4NNovZK1H+LEGfDyD+/iZSIDt1HGGvM1F63RGcZWomrJJW2M3zfPLYRzLnFYn/8EUGan 1icrETW7RsaSjw8V1LdD+CQFDgkqfBE70yl0Z1GgxFlRGTPx+nFkbXegIhTatPzKS4GQ fu7N6EuBjuF4fIo92T1RJEar93PqAQvgxBzPYUPUqTkD0jazlh8g/kKC0tV7sDNEa5f5 SwSg== X-Gm-Message-State: APjAAAVjRRo4Vq0fwmQtqPGbOhkfJWXW67uJQJcW6nrnc+52NTs+IJGW CCRJ4pUbflMAzt/616F3Rlw8Fhowvs1mHf947aw= X-Google-Smtp-Source: APXvYqzINzOB6LVxamVdkeHxEczOiUorj7Xwb5OfBeFbGI3iX/gGMRcnezE6w2YMEdPOa5LQaZfAvqhSKXYP2UhgjkQ= X-Received: by 2002:a92:3b98:: with SMTP id n24mr706259ilh.189.1578626470929; Thu, 09 Jan 2020 19:21:10 -0800 (PST) MIME-Version: 1.0 References: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> In-Reply-To: From: Rob Sayre Date: Thu, 9 Jan 2020 19:20:59 -0800 Message-ID: To: Glenn Deen Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000086a93059bc09e4c" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 03:21:14 -0000 --000000000000086a93059bc09e4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 6:59 PM Glenn Deen wrote: > On 9 Jan 2020, at 16:02, Rob Sayre wrote: > > > > Only the charter you proposed is that narrow, and I agree with other > > messages that say it's too narrow. The other two proposals, from Tommy > > Pauly and Ben Schwartz, are more broad. > > > That=E2=80=99s only somewhat true. ... It is definitely true, since the other proposals include the Adaptive DNS draft . My sense is that the charter debate isn't too important, and folks have moved on to implementation centered around Adaptive DNS. I'm going to do that too. If I come up with anything useful, it will be Apache 2 licensed. thanks, Rob --000000000000086a93059bc09e4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 9, 2020 at 6:59 PM Glenn Deen= <rgd.ietf@gmail= .com> wrote:
On 9 Jan 2020, at 16:02, Ro= b Sayre wrote:
>
> Only the charter you proposed is that narrow, and I agree with other > messages that say it's too narrow. The other two proposals, from T= ommy
> Pauly and Ben Schwartz, are more broad.


That=E2=80=99s only somewhat true.=C2=A0
...
=C2= =A0
It is definitely true, since the other proposals include the = Adaptive DNS draft .

My sense is that the charter = debate isn't too important, and folks have moved on to implementation c= entered around Adaptive DNS. I'm going to do that too. If I come up wit= h anything useful, it will be Apache 2 licensed.

t= hanks,
Rob
--000000000000086a93059bc09e4c-- From nobody Fri Jan 10 02:18:34 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236A212088A for ; Fri, 10 Jan 2020 02:18:33 -0800 (PST) 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 PZTxHtPIsJUZ for ; Fri, 10 Jan 2020 02:18:31 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 AFB99120096 for ; Fri, 10 Jan 2020 02:18:31 -0800 (PST) Received: from 200116b82cafa900d8adddaba4a4c379.dip.versatel-1u1.de ([2001:16b8:2caf:a900:d8ad:ddab:a4a4:c379]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iprN7-00049s-Ka; Fri, 10 Jan 2020 11:18:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 10 Jan 2020 11:18:28 +0100 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <33F807C3-69E1-4B2A-85DC-36DC8D883A11@kuehlewind.net> References: To: Rob Sayre , Tommy Pauly X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578651511;fff01ef8; X-HE-SMSGID: 1iprN7-00049s-Ka Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 10:18:33 -0000 > On 9. Jan 2020, at 21:43, Rob Sayre wrote: >=20 > I'd work on the Adaptive DNS draft, but if people are allergic to = adopting it and iterating, perhaps a bulleted list of the problems it = aims to solve would do. I don=E2=80=99t think people are allergic to adopting the draft. I think = people want to make sure that when adopted the scope of the current = draft can still be changed if agreed.=20 If it males people feel better about this charter, I think it would be = okay to remove the last sentence in the proposed charter, given that the = scope of draft-pauly-dprive-adaptive-dns-privacy is covered by the rest = of the charter text. However, I would understand =E2=80=9Cas a starting = point=E2=80=9D such that is the current content does not constrain the = scope of the charter and therefore, I also don=E2=80=99t see a problem = to leave it in. I think the important part is that there are people who want to work on = draft-pauly-dprive-adaptive-dns-privacy and I assume that the authors = will ask soon for adoption of this draft if this groups gets charter. So = when we talk about this charter, people should be aware of that. One more practical question: Currently = draft-pauly-dprive-adaptive-dns-privacy also proposed the use of = pauly-dprive-oblivious-doh. However, I assume that = pauly-dprive-oblivious-doh would actually stay in dprive as it seems = already in scope for that group; is that correct? =20= From nobody Fri Jan 10 02:35:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9351208A8 for ; Fri, 10 Jan 2020 02:35:36 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXOoDNYLr6EV for ; Fri, 10 Jan 2020 02:35:33 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 6E4E112010E for ; Fri, 10 Jan 2020 02:35:33 -0800 (PST) Received: from 200116b82cafa900d8adddaba4a4c379.dip.versatel-1u1.de ([2001:16b8:2caf:a900:d8ad:ddab:a4a4:c379]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iprda-0004X3-7h; Fri, 10 Jan 2020 11:35:30 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 10 Jan 2020 11:35:29 +0100 Cc: Ted Lemon , Alissa Cooper , Ben Schwartz , ADD Mailing list , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <7D42F41F-D47D-470F-8A8E-B58B8AE06AF9@kuehlewind.net> References: To: "Deen, Glenn (NBCUniversal)" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578652533;1ae699a6; X-HE-SMSGID: 1iprda-0004X3-7h Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 10:35:37 -0000 Hi Glen, See a few small comments inline=20 > On 9. Jan 2020, at 23:56, Deen, Glenn (NBCUniversal) = wrote: >=20 [snip] > =20 > [GD] As I said in my other notes =E2=80=93 Tommy=E2=80=99s version is = very similar in its goals which is a very good sign. The main = difference is how much and what you front load the WG with constraints = on where they start and how they have to proceed. > =20 > The areas that I would change would be to remove a few things: > =20 > =E2=80=A2 I would remove the following since I think the getting = into informing clients of what is appropriate is both a can of worms, = and gets into the realm of telling the clients what to choose versus the = clients pulling the information they want and then making their choice = based on whatever logic they have in the client. > =20 > - inform clients about how to select appropriate encrypted and = unencrypted resolvers for DNS queries in various network environments = and use cases. So this is the only part in the proposed charter that actually talk = about selection. If you want to work on discovery AND selection the = charter should say that. Maybe this point as currently phrased a bit too = broad and we can be more concrete here?=20 I would also be okay to say for now that the group will work on = discovery mechanism first and advance selection mechanisms need = rechartering. However, as I said in a previous mail, I don=E2=80=99t = think we can design the discovery mechanisms correctly if we don=E2=80=99t= have at least a few simple selection policies in mind that could be = used. > =20 > 2. Remove (below) the Adaptive DNS draft starting point because as = it currently is Adaptive DNS goes beyond D&S and gets into interesting = areas of resolver behavior including the MUST requirement that DoH = servers support ubiquitous DNS. That=E2=80=99s more than D&S as I say = is interesting but it=E2=80=99s far more than the WG should try to take = on if it wants to be able to reasonably deliver output. BTW =E2=80=93 = I=E2=80=99m not saying don=E2=80=99t discuss such things. I am simply = saying such things would better be done in another WG. > =20 > The starting point for the group's work is Adaptive DNS = (draft-pauly-dprive-adaptive-dns-privacy), subject tothe working group's = design choices. See my other mail I=E2=80=99ve just sent. > =20 > =E2=80=A2 I would also do an edit to make sure it is not = specific to DoH and DoT and make it about any DNS. The current rev. = mentions unencrypted DNS in some places and focuses on DoH in others. = Both Encrypted DNS and even traditional DNS/53 since if the group were = to produce a better way of discovering and selecting DNS resolvers there = isn=E2=80=99t any reason to limit its use to encrypted DNS. Network = environments like enterprises that may choose to use DNS/53 could = benefit from it. =20 > =20 > =E2=80=A2 I continue to advocate for changing the name to not be = ADD. Too much baggage comes with it. I continue to propose the simpler = DNS Discovery and Selection or DNS-DS DNS-DS might be confusing with RFC6763 (DNS-Based Service Discovery). Mirja From nobody Fri Jan 10 02:38:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF39120110 for ; Fri, 10 Jan 2020 02:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, 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 Ur9C165B_b3j for ; Fri, 10 Jan 2020 02:38:52 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FC21200BA for ; Fri, 10 Jan 2020 02:38:52 -0800 (PST) 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 8262E6A257; Fri, 10 Jan 2020 11:38:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578652730; bh=8gF8S5DXfiG3T8LOWyE6pY0nyqv1sQKw2XDh8sB6tww=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=38k/JmBRwoZdxYg88TOTCmE/OFouwE20j02GZwo0hVJ0Uv67sfYxzx/PwU5tixvJ2 OAoHJ4CKcMidEvc0du1jlaaHk5O558spxnlwM0fFrUQj/mqqMOaWnvdjEwAzjInMvr 03mUDOCq5ssHuqf8Pc6yHrEjbHiv/sbeI3bFy44qc1UK7QIdddIJCFyXfXFcZMweuG cWYrXVkN6oF+QcvNQPjkrlCcMf+o25m8FAwRjmI5WUTGybHbCxF3cCqbRS846DrBqR zqKvyQWXBOLNufbcQGAot6Q9GqP5MeEsMc7X+HR1gKh7QP9zRfV/I2csKHA9QNRzk5 1SnQfB05EOgmw== 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 74D4B3C05BD; Fri, 10 Jan 2020 11:38:50 +0100 (CET) Date: Fri, 10 Jan 2020 11:38:48 +0100 (CET) From: Vittorio Bertola To: Eric Rescorla , "STARK, BARBARA H" Cc: ADD Mailing list Message-ID: <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> In-Reply-To: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.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.3-Rev3 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] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 10:38:55 -0000 =20 =20

Il 09/01/2020 23:01 Eric Rescorla <ekr@rtfm.com> ha scritto:




On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H < bs7652@att.com> wrote:

 <bhs> There would totally be a p= oint in implementing it. There are many usage scenarios where the administr= ator or user of the device trusts (or can determine whether they trust) a n= etwork. Just because DHCP isn=E2=80=99t the right solution for all scenario= s, doesn=E2=80=99t mean it isn=E2=80=99t the right solution for some (or ev= en many) scenarios. If a user can be asked whether or not the network is pu= blic or private, or the administrator can install software that can determi= ne if the device is on a trusted network, then the device can use a combina= tion of admin policy and user input to decide whether or not to ask for / u= se DHCP options. Just because the DHCP option is provided, doesn=E2=80=99t = mean you have to use it. If a device doesn=E2=80=99t use it, we=E2=80=99re = no worse off than now, with no DHCP option specified. If the device does us= e it, then we=E2=80=99ve at least provided a solution for those usage scena= rios where the network is trusted. Right now, we=E2=80=99re holding =E2=80= =9Cnetworks trusted by the user/admin=E2=80=9D hostage until some convolute= d solution can be created that adds complexity and confusion for the user a= nd only serves to shift who the user/admin has to trust (but doesn=E2=80=99= t necessarily make things more secure or private).


Can you explain your threat model here? If the network is trusted, th= en what are you gaining by encrypting the DNS traffic? As I mentioned, ther= e seem to be a few edge cases where this might have some value, but I'd lik= e to understand what it is you have in mind.
I can't speak for Barbara, but I generally agree that encrypting the DNS= transport channel is very important if you want to connect to a faraway pu= blic resolver over a network that you distrust, much less so if you want to= connect to a local resolver over a trusted network (though an attacker cou= ld still manage to penetrate the local network, so there is still value in = it).

But please keep in mind that there are also strong non-technical dynamic= s at play here. The web industry has (rightfully) spent years to convince u= sers that "encrypted =3D good, unencrypted =3D bad". As global public resol= vers go encrypted and browsers promote encrypted DNS as an important securi= ty feature, local network administrators will also be forced to encrypt com= munications with the local resolver, otherwise their users and their boss w= ill cry "hey, how come our resolver is still unencrypted? you are putting u= s at risk!". It doesn't matter that the threat model is different - users a= nd management will still demand encryption for the sake of encryption.

-- 

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 Fri Jan 10 03:17:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3F11208A8 for ; Fri, 10 Jan 2020 03:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un-17E-rAtPw for ; Fri, 10 Jan 2020 03:17:54 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110081.outbound.protection.outlook.com [40.107.11.81]) (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 33FAA120013 for ; Fri, 10 Jan 2020 03:17:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EddOYPpNs61msia+e1aRi5znseQduYBjkLSrr1Hc8Sy+QUnfF+9lRcggRuYixbFq0Wg4MMwxXpPkNpkOHqhS4d0G1ngSljcxZsQTQxmpy9XdMBnL6526DWRHirQwN214osYoVT66+XdFBUnE1dRaCovvlggF/f8p8dOwKL9N8mKUL2McQJYROWNdo6W695ThLjlBkpb33m1O3jDk+ZSu40YFGVsQ7HeONEpVZmmY0YRTBfcNcd7NMRaj2ZhHPRZ5d3RAamd3AIN6w+VYt2gsjbyFsVNATqX29tVry8ZRpOhuxNfTEbUUqtMh9+IKKsIf5UcFgkPRwDJOwtKiuanzxA== 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=77Jrg8O/CyqBhL+F7zBADIRyndJ29YwLeeWN5MZ9fK4=; b=EbTBojTy27ENEx1opz8mghgApgDblM/7/IaZ1OAFcHUu83YsnrhkKCoRopSexXYLgTbmcZYYxxKT53AoSQ+N7oIm1YEvJDOs4L2sZ3lbUDWkjQJwuCduD91PDBxwJW2isvO5xHHl3GK4lTVI3ScSDR8SZA33VqEsteQ3YimYk0snks+jOQfWrTGiZ8urmTf15GuSlaVM7LOP4Kvf0DeawSjItDUjF77berMNMvBMpR3aT0LmknXEq5IMiq4KIxpE9/HrI3KCxwAC3KSvIRdr3whtcmtWP0EPsLBkafmVSxOl9pWL8baV2JLh34CRvEK28I0k0kdzZ454nLBk5z/3Mg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=77Jrg8O/CyqBhL+F7zBADIRyndJ29YwLeeWN5MZ9fK4=; b=g9i3I8depGSRim1d2hM3AUKI7EktKJ5SHn4KxtRtfP7xyhE4NC6NnuzM0MtH/QaOirYzljAq92pc97Z+DnkM0qM3+1kyw7jIARza/xHyoqq7LjyUodl8W/Y5dOYAEvxPtjKSZ5TZUMfyDrvgXf2/7JZ5w9XEH0Bn6tIZQz4xtuQ= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1264.GBRP265.PROD.OUTLOOK.COM (20.176.140.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.8; Fri, 10 Jan 2020 11:17:41 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.011; Fri, 10 Jan 2020 11:17:41 +0000 From: Andrew Campling To: Glenn Deen , ADD Mailing list Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVx6IujmrYs3rjXEyN9WVpGFBH4afjv31w Date: Fri, 10 Jan 2020 11:17:41 +0000 Message-ID: References: <43AEEA2D-1BDB-4A56-BC32-A89A96588951@nbcuni.com> 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=andrew.campling@419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ced8d82-f4a5-4bd9-db0e-08d795beb573 x-ms-traffictypediagnostic: LO2P265MB1264: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(346002)(39830400003)(396003)(199004)(189003)(13464003)(5660300002)(53546011)(76116006)(52536014)(66476007)(66446008)(9686003)(66946007)(66556008)(30864003)(64756008)(55016002)(71200400001)(6506007)(508600001)(44832011)(33656002)(2906002)(966005)(8936002)(86362001)(7696005)(316002)(110136005)(8676002)(186003)(81166006)(81156014)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1264; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: re82H5vjufqbJhtUOvj35ya4KvGPLsV0PwIPOuX4I1+6nYSnEU3bD3JjzHvCHBbxtErCqp+U3NiT/wcnC4FgXz/XgmCSOsw2O04fOSPk57TZwddzaPMnDd/+54TF5t5S532Ik8mHBwSwUZwbCzs50EQSF+eX2wrD4b/f+Om1dQqRqP6Bx9tiY98+mh2FcFtjUy2QaoJRnHf+gxAVYhdBMB9cew0wWZJXhlkTnHgXuezEO+3cg0eYIyjlwsodmjp9g4KtTkX1ihBNt0K5D/9kDWg7I+p7C0fUxdd1a0CjDuLufeYtzo1L3rVgm6VZ2sZxZSpbnPxQVPixUremOKCEvr2oxM1kGdtC9h32rTPuzzX1qGzihtyc12rrW1pb9GvWcEUOx9+eQyOhJlUCWBZsltENJhRmZhuMdlXycJGUdi5T19xQ6QI4Wtn7a9ffujVs2XOIDo6g9whuoGqUfpIshtmsGoJYNf8qcJDxjyZMWPA+s+rpPdZMThWMkA19a3ZF/KRpQklDo+9MCa7Qw70S/w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573C3B9C68DD37A9A5513DDC2380LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 2ced8d82-f4a5-4bd9-db0e-08d795beb573 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 11:17:41.5528 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IT3FoL8qGTMW+soK7bXjTnkRudatpSJkigq3UDIMZSV2mMEyo43dVmFBovEzjYoHZEqdTCrPwZpNiO5W95EXFtZ1gRxWQvQUJcAL0o4HRyk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1264 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 11:17:58 -0000 --_000_LO2P265MB0573C3B9C68DD37A9A5513DDC2380LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBHbGVubidzIHByb3Bvc2FsIHByb3ZpZGVzIHRoZSBiZXN0IGJhc2lzIG9uIHdoaWNo IHRvIGJ1aWxkIGEgV0cgY2hhcnRlci4NCg0KQW5kcmV3DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBHbGVubiBEZWVuIDxyZ2QuaWV0ZkBnbWFpbC5jb20+DQpTZW50OiAxMCBK YW51YXJ5IDIwMjAgMDI6NTkNClRvOiBBREQgTWFpbGluZyBsaXN0IDxhZGRAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW0FkZF0gQSBwcm9wb3NlZCBjaGFydGVyIGZvciBBQkNEDQoNCk9uIDkgSmFu IDIwMjAsIGF0IDE2OjAyLCBSb2IgU2F5cmUgd3JvdGU6DQoNCj4gT24gVGh1LCBKYW4gOSwgMjAy MCBhdCAzOjU4IFBNIEdsZW5uIERlZW4gPHJnZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86cmdkLmll dGZAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+Pg0KPj4NCj4+IE9uIFRodSwgSmFuIDksIDIwMjAg YXQgMzo0OCBQTSBSb2IgU2F5cmUgPHNheXJlckBnbWFpbC5jb208bWFpbHRvOnNheXJlckBnbWFp bC5jb20+PiB3cm90ZToNCj4+DQo+Pj4gT24gVGh1LCBKYW4gOSwgMjAyMCBhdCAzOjA1IFBNIERl ZW4sIEdsZW5uIChOQkNVbml2ZXJzYWwpIDwNCj4+PiBHbGVubi5EZWVuQG5iY3VuaS5jb208bWFp bHRvOkdsZW5uLkRlZW5AbmJjdW5pLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IE9uIDEvOS8yMCwg MTI6NDQgUE0sICJSb2IgU2F5cmUiIDxzYXlyZXJAZ21haWwuY29tPG1haWx0bzpzYXlyZXJAZ21h aWwuY29tPj4gd3JvdGU6DQo+Pj4+DQo+Pj4+IEknbSBub3Qgc3VyZSB3aGF0IEdsZW5uIG1lYW5z IGJ5ICJyZXNvbHZlciBiZWhhdmlvciIuIERvZXMgdGhhdA0KPj4+PiBtZWFuIGNsaWVudCBiZWhh dmlvcj8gSSBsb29rZWQgYXQgdGhlIGRyYWZ0IGFnYWluIGFuZCBkaWRuJ3QgZmluZA0KPj4+PiBh bnkgcmVxdWlyZW1lbnRzIG9uIHNlcnZlcnMgdGhhdCB3b3VsZCBiZSBpbmNvbXBhdGlibGUgd2l0 aA0KPj4+PiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIHRob3VnaCBvZiBjb3Vyc2UgdGhlcmUg YXJlIHNvbWUgbmV3DQo+Pj4+IGNhcGFiaWxpdGllcyBhcm91bmQgZGlzY292ZXJ5IGFuZCBzZWxl Y3Rpb24uDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IFtHRF0gSSB3YXMgcmVmZXJyaW5nIHRvIHRo ZSBzZWN0aW9uIG9uIHNlcnZlciBiZWhhdmlvciBpbiBzZWN0aW9uIDQNCj4+Pj4gb2YgdGhlIGRy YWZ0Lg0KPj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGF1bHktZHByaXZl LWFkYXB0aXZlLWRucy1wcml2YWN5DQo+Pj4+IC0wMQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBN eSBvYmplY3Rpb24gYmVpbmcgdGhhdCBpdOKAmXMgb3V0IG9mIHNjb3BlIGZvciBhIFdHIGZvY3Vz ZWQgb24gRCZTLA0KPj4+PiBpdCBpcyBhbiBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIGJ1dCBJIHRo aW5rIGZpdHMgaW50byBEUFJJVi4NCj4+Pj4NCj4+Pg0KPj4+IEkgc2VlLiBTb21lIHBhcnRzIG9m IFNlY3Rpb24gNCBhcmUgc3RyYWlnaHRmb3J3YXJkbHkgYWJvdXQgZGlzY292ZXJ5DQo+Pj4gYW5k IHNlbGVjdGlvbiAoZm9yIGV4YW1wbGU6ICJDbGllbnRzIGNhbiB1c2UgdGhpcyBsaXN0IHRvIG9w dGltaXplDQo+Pj4gbG9va3VwcyBmb3IgY29tbW9uIG5hbWVzLiIpLg0KPj4+DQo+Pj4gUGVyaGFw cyB0aGUgaXNzdWUgaXMgT2JsaXZpb3VzIERvSD8gSXQgc2VlbXMgdG8gbWUgdGhhdCBzdXBwb3J0 IGZvcg0KPj4+IHRoYXQgY291bGQgYmUgYW4gaW1wb3J0YW50IHBhcnQgb2YgcmVzb2x2ZXIgc2Vs ZWN0aW9uIGZvciBzb21lDQo+Pj4gY2xpZW50cywgYW5kIGl0IHdpbGwgY2hhbmdlIHRoZSBETlMg ZWNvc3lzdGVtLiBIb3dldmVyLCBpdCBhbHNvDQo+Pj4gc2VlbXMgdG8gbWUgdGhhdCBpdCdzIG5v dCBhIHByb3RvY29sIHRoYXQgY2FuIGJlIHByZXZlbnRlZCBub3cgdGhhdA0KPj4+IERvSCBpcyBk ZXBsb3llZC4NCj4+Pg0KPj4NCj4+DQo+PiBNeSBvYmplY3Rpb24gaGVyZSBpcyBhYm91dCBhZGRp bmcgaXQgdG8gYSB3ZyBmb2N1c2VkIG9uIEQmUyBieQ0KPj4gY2xpZW50czsgIGlzbuKAmXQgaGVs cGZ1bCB0byBrZWVwaW5nIHRoZSBEJlMgZm9jdXNlZCBhbmQgb24gdHJhY2suDQo+Pg0KPj4gU3Vy ZSB0aGVyZSBtYXliZSBpbmZvcm1hdGlvbiB0byBjb252ZXkgdG8gY2xpZW50cyB0aGF0IHRoZXkg Y2FuIHVzZQ0KPj4gaW4NCj4+IHRoZWlyIHNlbGVjdGlvbiBjaG9pY2UuICAgVGhhdCB3b3VsZCBi ZSBpbiBzY29wZS4gICBJdOKAmXMgdGhlIHBhcnQNCj4+IHdoZXJlIGl0DQo+PiBnZXRzIGludG8g c3BlY2lmeWluZyB0aGUgYmVoYXZpb3Igb2YgdGhlIHJlc29sdmVycyB0aGF0IGdldHMgdG8gYmUN Cj4+IHRvbyBmYXIgZnJvbSBEJlMuDQo+Pg0KPj4gVGhpcyBuZXcgcG90ZW50aWFsIGdyb3VwIHdl IGFyZSBkaXNjdXNzaW5nIGlzbuKAmXQgYSBicm9hZCBncm91cCBhYm91dA0KPj4gZG5zIHByaXZh Y3kgLCB3ZSBhbHJlYWR5IGhhdmUgRHByaXYgZm9yIHRoYXQgc3R1ZmYuDQo+Pg0KPg0KPiBPbmx5 IHRoZSBjaGFydGVyIHlvdSBwcm9wb3NlZCBpcyB0aGF0IG5hcnJvdywgYW5kIEkgYWdyZWUgd2l0 aCBvdGhlcg0KPiBtZXNzYWdlcyB0aGF0IHNheSBpdCdzIHRvbyBuYXJyb3cuIFRoZSBvdGhlciB0 d28gcHJvcG9zYWxzLCBmcm9tIFRvbW15DQo+IFBhdWx5IGFuZCBCZW4gU2Nod2FydHosIGFyZSBt b3JlIGJyb2FkLg0KDQoNClRoYXTigJlzIG9ubHkgc29tZXdoYXQgdHJ1ZS4gIEFsbCB0aHJlZSBm b2N1cyBvbiBEaXNjb3ZlcnkgYW5kIFNlbGVjdGlvbiBhbmQgZXZlbiB0aGUgb25lIEkgcHJvcG9z ZWQgaXNu4oCZdCBhY3R1YWxseSBhbGwgdGhhdCBuYXJyb3cgc2luY2UgaXQgZGVmZXJzIHRvIHRo ZSBXRyBhbmQgdGhlIEFEcyBvbiB3aGVyZSB0aGV5IG5lZWQgdG8gZ28uDQoNClNldmVyYWwgY29t bWVudHMgb24gb3RoZXIgcHJvcG9zYWxzIHdlcmUgY29uY2VybmVkIHRoYXQgdGhleSB3ZXJlIG9w ZW5pbmcgdXAgcG90ZW50aWFsIHJhdGhvbGVzIGluIHRoZWlyIHNjb3BlIGFuZCBhbHJlYWR5IHRo ZXJlIGlzIGEgd2hvbGUgdGhyZWFkIGdvaW5nIG9uIGhlcmUgb24gQUREIGFib3V0IHdoYXQgVHJ1 c3QgbWVhbnMgaW4gYSB2YXJpZXR5IG9mIGNvbnRleHRzLiBBIGxvdCBvZiB0aGF0IGlzIGJlY2F1 c2UgdGhlIFRvbW15IFBhdWwgYW5kIEJlbiBTY2h3YXJ0eiBwcm9wb3NhbHMgcHVsbGVkIGluIHdv cmsgYmV5b25kIEQmUyBhbmQgZ290IGludG8gc29tZSBkaXNjdXNzaW9uIGFib3V0IHJlc29sdmVy IGJlaGF2aW9yIGFuZCBldmVuIHBvbGljeSB2aWEgdGhlIGRyYWZ0cyB0aGV5IG1lbnRpb25lZC4N Cg0KSeKAmW0gbm90IHRyeWluZyB0byBjdXJ0YWlsaW5nIGFueSBvZiB0aGVzZSBvdGhlciBkaXNj dXNzaW9ucyBpZiBwZW9wbGUgd2FudCB0byBoYXZlIHRoZW0sIGJ1dCB0aGVzZSBldmVyIG9uZ29p bmcgcG9zdGluZ3Mgb24gdGhlIEFERCBsaXN0IGhhdmUgbWFkZSB2ZXJ5IGxpdHRsZSBwcm9ncmVz cyB0byBubyBwcm9ncmVzcyB0b3dhcmQgcmVzb2x1dGlvbi4gTWVhbndoaWxlIHdlIGhhdmUgRW5j cnlwdGVkIEROUyBkZXBsb3ltZW50cyBnb2luZyBvbiB0aGF0IGhhdmUgYSBjcml0aWNhbCBuZWVk IGZvciBzY2FsYWJsZSBhbmQgcHJhY3RpY2FsIGRpc2NvdmVyeSBhbmQgc2VsZWN0aW9uLiAgUHVs bGluZyB0b28gbXVjaCBvZiB0aGF0IGludG8gdGhlIFdHIGp1c3QgYWRkcyB0byB0aGUgcXVpY2tz YW5kIHRoZSBncm91cCBuZWVkcyB0byB3YWRlIHRocm91Z2guIFRoaXMgd2hvbGUgYXJlYSBpcyBz dWNoIGEgYnJvYWQgdG9waWMgYXJlYSB3aXRoIG5vIHNob3J0YWdlIG9mIG9waW5pb25zLCB2aXNp b24sIG9yIGNyZWF0aXZpdHkgLSBidXQgYXQgc29tZSBwb2ludCB0aGVyZSBpcyBhIG5lZWQgdG8g ZG8gdHJpYWdlIGFuZCBnZXQgYnVzeSBvbiBoaWdoZXN0IHByaW9yaXR5IG5lZWQuDQoNCk15IHBy b3Bvc2FsIHdhcyBzaW1wbHkgdG8gYnJlYWsgdGhlIGxvZyBqYW0gYW5kIGdldCBzb21lIHJlYWwg d29yaw0Kc3RhcnRlZC4gICBJZiB0aGUgQURzIHdhbnQgdG8gZXhwYW5kIHRoZSBXRyBzY29wZSBh dCBhbnl0aW1lIGVpdGhlciBkYXkNCjEgb3IgZGF5IDEwMCBvZiB0aGUgV0figJlzIGxpZmUsIGFz ICBUZWQgTC4gcG9pbnRlZCBvdXQgZWFybGllciB0b2RheSwgdGhleSAgY2FuLg0KDQpBbGwgMyBw cm9wb3NhbHMgaGF2ZSBnb29kIGJvbmVzIGluIG15IG9waW5pb24sIGJ1dCBJIGJlbGlldmUgdGhh dCB0aGUgZ3JvdXAgd2lsbCBiZSBwcmltZWQgZm9yIGEgaGlnaGVyIGNoYW5jZSBvZiBzdWNjZXNz IGlmIGl0IGNhbiBzdGFydCBieSBub3QgdHJ5aW5nIHRvIGJpdGUgb2ZmIHRvbyBiaWcgYSBmaXJz dCBiaXRlLiBXaGF0ZXZlciBwcm9wb3NhbCBpcyBSRVbigJlkIHRvIHByb2R1Y2UgYSB3b3JrYWJs ZSBjaGFydGVyIGlzIGZpbmUuICBJIGV2ZW4gcG9zdGVkIGFuIGVkaXRlZCB2ZXJzaW9uIG9mIHRo ZSBQYXVseSBwcm9wb3NhbCBhIGxpdHRsZSBlYXJsaWVyIGluIHJlc3BvbnNlIHRvIFRlZOKAmXMg cXVlc3Rpb24gb2YgaG93IEkgd291bGQgZWRpdCB0aGF0IHByb3Bvc2FsLg0KDQpBcyBmb3IgY29t bWVudHMgcmVjZWl2ZWQ6IEnigJlsbCBub3RlIHRoYXQgd2hpbGUgdGhlcmUgaGF2ZSBiZWVuIHBv c3RzIGFzc2VydGluZyB0aGF0IHRoZXnigJlkIGxpa2UgWCBvciBZIGluY2x1ZGVkLCBvciBpbiBv bmUgY2FzZSB0aGF0IHRoZXnigJlkIHdhbnQgdG8gc2VlIERIQ1AgZXhjbHVkZWQsIHRoZXJlIGhh dmUgYWxzbyBiZWVuIGEgY291cGxlIG9mIHBvc3RzIGluIHN1cHBvcnQgb2Ygd2hhdCBJIHdyb3Rl IGFuZCB3aGlsZSBzb21lIHNhaWQgaXQgbWF5IG5vdCBpbmNsdWRlIGV2ZXJ5dGhpbmcgdGhleSBt aWdodCB3YW50IC0gdGhleSBjb3VsZCBsaXZlIHdpdGggaXQgYXMgYSBzdGFydC4NCg0KQmVpbmcg cmVhbGlzdGljLCBldmVuIGxpbWl0aW5nIHRoZSB3b3JrIHRvIERpc2NvdmVyeSBhbmQgU2VsZWN0 aW9uIGdpdmVzIHRoZSBXRyBhIGxvdCBvZiB3b3JrIHRvIGRvLCBhbmQgaGFyZCB3b3JrIGF0IHRo YXQuICBXZSBhbHJlYWR5IGhhdmUgZGlmZmVyZW50IEQmUyBhcHByb2FjaGVzIGJlaW5nIHB1dCBv biB0aGUgdGFibGUgdGhhdCB3aGVuIHlvdSBkaWcgaW50byB0aGVtIGFyZSBwcmV0dHkgZmFyIGFw YXJ0IGFuZCB0aGUgV0cgaGFzbuKAmXQgZXZlbiBvcGVuZWQgaXRzIGRvb3IgZm9yIGRyYWZ0IHN1 Ym1pc3Npb25zLiAgUHJvcG9zYWxzIHJhbmdlIGZyb20gdGhlIGNsaWVudCBnZXR0aW5nIHRoZSBp bmZvIGZyb20gdGhlIG5ldHdvcms7IGZyb20gYSBkb21haW4gY29tbXVuaWNhdGluZyAgd2hhdCB0 aGUgRE5TIHNlcnZpY2VzIGl0IHJlY29tbWVuZHM7IGNsZXZlciBhcHBsaWNhdGlvbnMgb2YgRE5T U0VDOyBzb21lIGFkdm9jYXRpbmcgYXBwbGljYXRpb25zIG9mIERIQ1A7IGFuZCBvdGhlcnMuICBX ZSBhbHNvIGFscmVhZHkgaGF2ZSBhIGNsaWVudCBkZXBsb3llZCBpbiB0aGUgd2lsZCB0aGF0IGNv bWVzIHdpdGggdGhlIGxpc3QgYnVpbHQgaW50byB0aGUgY2xpZW50IHdoaWNoIHRoZW4gY29tYmlu ZXMgdGhhdCB3aXRoIHRoZSBjbGllbnRzIGN1cnJlbnQgRE5TLzUzIHNldHRpbmdzIHRvIG1ha2Ug aXRzIGRlY2lzaW9uLiBTbyBubyBzaG9ydGFnZSBvZiBhcHByb2FjaGVzLiAgVGhpcyBpc27igJl0 IGFib3V0IGJlaW5nIG5hcnJvdyBzbyBhcyB0byBzaWRlc3RlcCBpbnRlcmVzdGluZyBwcm9wb3Nh bHMgb24gaG93IHRvIGV2b2x2ZSBETlMsIGl0IGlzIGluc3RlYWQgYWJvdXQgdGFraW5nIGEgZmly c3QgYml0ZSB0aGF0IGhhcyBhbiBhY3R1YWwgY2hhbmNlIG9mIHByb2dyZXNzIGluIGEgcmVhc29u YWJsZSB0aW1lIGZyYW1lLg0KDQoNCkdsZW5uDQoNCg0KDQoNCg== --_000_LO2P265MB0573C3B9C68DD37A9A5513DDC2380LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQ7Ij4NCjxkaXY+SSB0aGluayBHbGVubidzIHByb3Bvc2FsIHByb3Zp ZGVzIHRoZSBiZXN0IGJhc2lzIG9uIHdoaWNoIHRvIGJ1aWxkIGEgV0cgY2hhcnRlci48L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiPkFuZHJldyA8L2I+PC9kaXY+DQo8YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjwvYT4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KDQpGcm9tOiBHbGVubiBEZWVuICZsdDtyZ2QuaWV0ZkBnbWFp bC5jb20mZ3Q7IDxicj4NCg0KU2VudDogMTAgSmFudWFyeSAyMDIwIDAyOjU5PGJyPg0KDQpUbzog QUREIE1haWxpbmcgbGlzdCAmbHQ7YWRkQGlldGYub3JnJmd0Ozxicj4NCg0KU3ViamVjdDogUmU6 IFtBZGRdIEEgcHJvcG9zZWQgY2hhcnRlciBmb3IgQUJDRDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+T24gOSBKYW4gMjAyMCwgYXQgMTY6MDIsIFJvYiBTYXlyZSB3cm90ZTo8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgT24gVGh1LCBKYW4gOSwgMjAyMCBhdCAzOjU4 IFBNIEdsZW5uIERlZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyZ2QuaWV0ZkBnbWFpbC5jb20iPnJn ZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IE9u IFRodSwgSmFuIDksIDIwMjAgYXQgMzo0OCBQTSBSb2IgU2F5cmUgJmx0OzxhIGhyZWY9Im1haWx0 bzpzYXlyZXJAZ21haWwuY29tIj5zYXlyZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBPbiBUaHUsIEphbiA5LCAy MDIwIGF0IDM6MDUgUE0gRGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkgJmx0OyA8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpHbGVubi5EZWVuQG5iY3VuaS5jb20iPkds ZW5uLkRlZW5AbmJjdW5pLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAxLzkvMjAsIDEyOjQ0IFBNLCAmcXVv dDtSb2IgU2F5cmUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYXlyZXJAZ21haWwuY29tIj5z YXlyZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyBJJ20gbm90IHN1cmUgd2hhdCBHbGVubiBt ZWFucyBieSAmcXVvdDtyZXNvbHZlciBiZWhhdmlvciZxdW90Oy4gRG9lcyB0aGF0IDwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IG1lYW4gY2xpZW50IGJlaGF2aW9yPyBJIGxvb2tlZCBhdCB0 aGUgZHJhZnQgYWdhaW4gYW5kIGRpZG4ndCBmaW5kIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7IGFueSByZXF1aXJlbWVudHMgb24gc2VydmVycyB0aGF0IHdvdWxkIGJlIGluY29tcGF0aWJs ZSB3aXRoIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IGV4aXN0aW5nIGltcGxlbWVudGF0 aW9ucywgdGhvdWdoIG9mIGNvdXJzZSB0aGVyZSBhcmUgc29tZSBuZXcgPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jmd0OyZndDsgY2FwYWJpbGl0aWVzIGFyb3VuZCBkaXNjb3ZlcnkgYW5kIHNlbGVjdGlv bi48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 Jmd0OyBbR0RdIEkgd2FzIHJlZmVycmluZyB0byB0aGUgc2VjdGlvbiBvbiBzZXJ2ZXIgYmVoYXZp b3IgaW4gc2VjdGlvbiA0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoZSBkcmFm dC48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtcGF1bHktZHByaXZlLWFkYXB0aXZlLWRucy1wcml2YWN5Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGF1bHktZHByaXZlLWFkYXB0aXZlLWRucy1w cml2YWN5PC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IC0wMTwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IE15IG9iamVjdGlv biBiZWluZyB0aGF0IGl04oCZcyBvdXQgb2Ygc2NvcGUgZm9yIGEgV0cgZm9jdXNlZCBvbiBEJmFt cDtTLCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyBpdCBpcyBhbiBpbnRlcmVzdGluZyBk aXNjdXNzaW9uIGJ1dCBJIHRoaW5rIGZpdHMgaW50byBEUFJJVi48L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7IEkgc2VlLiBTb21lIHBhcnRzIG9mIFNlY3Rpb24gNCBhcmUgc3RyYWlnaHRmb3J3YXJkbHkg YWJvdXQgZGlzY292ZXJ5IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgYW5kIHNlbGVjdGlvbiAo Zm9yIGV4YW1wbGU6ICZxdW90O0NsaWVudHMgY2FuIHVzZSB0aGlzIGxpc3QgdG8gb3B0aW1pemUg PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBsb29rdXBzIGZvciBjb21tb24gbmFtZXMuJnF1b3Q7 KS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBQZXJo YXBzIHRoZSBpc3N1ZSBpcyBPYmxpdmlvdXMgRG9IPyBJdCBzZWVtcyB0byBtZSB0aGF0IHN1cHBv cnQgZm9yIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgdGhhdCBjb3VsZCBiZSBhbiBpbXBvcnRh bnQgcGFydCBvZiByZXNvbHZlciBzZWxlY3Rpb24gZm9yIHNvbWUgPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jmd0OyBjbGllbnRzLCBhbmQgaXQgd2lsbCBjaGFuZ2UgdGhlIEROUyBlY29zeXN0ZW0uIEhv d2V2ZXIsIGl0IGFsc28gPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBzZWVtcyB0byBtZSB0aGF0 IGl0J3Mgbm90IGEgcHJvdG9jb2wgdGhhdCBjYW4gYmUgcHJldmVudGVkIG5vdyB0aGF0IDwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgRG9IIGlzIGRlcGxveWVkLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgTXkgb2JqZWN0aW9uIGhlcmUgaXMgYWJvdXQgYWRkaW5nIGl0IHRvIGEgd2cg Zm9jdXNlZCBvbiBEJmFtcDtTIGJ5IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBjbGllbnRzOyZuYnNw OyBpc27igJl0IGhlbHBmdWwgdG8ga2VlcGluZyB0aGUgRCZhbXA7UyBmb2N1c2VkIGFuZCBvbiB0 cmFjay48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgU3VyZSB0aGVy ZSBtYXliZSBpbmZvcm1hdGlvbiB0byBjb252ZXkgdG8gY2xpZW50cyB0aGF0IHRoZXkgY2FuIHVz ZSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgaW48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgdGhlaXIgc2Vs ZWN0aW9uIGNob2ljZS4mbmJzcDsmbmJzcDsgVGhhdCB3b3VsZCBiZSBpbiBzY29wZS4mbmJzcDsm bmJzcDsgSXTigJlzIHRoZSBwYXJ0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyB3aGVyZSBpdDwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyBnZXRzIGludG8gc3BlY2lmeWluZyB0aGUgYmVoYXZpb3Igb2YgdGhl IHJlc29sdmVycyB0aGF0IGdldHMgdG8gYmUgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IHRvbyBmYXIg ZnJvbSBEJmFtcDtTLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBU aGlzIG5ldyBwb3RlbnRpYWwgZ3JvdXAgd2UgYXJlIGRpc2N1c3NpbmcgaXNu4oCZdCBhIGJyb2Fk IGdyb3VwIGFib3V0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBkbnMgcHJpdmFjeSAsIHdlIGFscmVh ZHkgaGF2ZSBEcHJpdiBmb3IgdGhhdCBzdHVmZi48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4N CjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IE9ubHkgdGhlIGNoYXJ0ZXIgeW91IHByb3Bvc2Vk IGlzIHRoYXQgbmFycm93LCBhbmQgSSBhZ3JlZSB3aXRoIG90aGVyIDwvZGl2Pg0KPGRpdj4mZ3Q7 IG1lc3NhZ2VzIHRoYXQgc2F5IGl0J3MgdG9vIG5hcnJvdy4gVGhlIG90aGVyIHR3byBwcm9wb3Nh bHMsIGZyb20gVG9tbXkgPC9kaXY+DQo8ZGl2PiZndDsgUGF1bHkgYW5kIEJlbiBTY2h3YXJ0eiwg YXJlIG1vcmUgYnJvYWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+VGhhdOKAmXMgb25seSBzb21ld2hhdCB0cnVlLiZuYnNwOyBBbGwgdGhyZWUgZm9j dXMgb24gRGlzY292ZXJ5IGFuZCBTZWxlY3Rpb24gYW5kIGV2ZW4gdGhlIG9uZSBJIHByb3Bvc2Vk IGlzbuKAmXQgYWN0dWFsbHkgYWxsIHRoYXQgbmFycm93IHNpbmNlIGl0IGRlZmVycyB0byB0aGUg V0cgYW5kIHRoZSBBRHMgb24gd2hlcmUgdGhleSBuZWVkIHRvIGdvLjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+U2V2ZXJhbCBjb21tZW50cyBvbiBvdGhlciBwcm9wb3NhbHMgd2VyZSBj b25jZXJuZWQgdGhhdCB0aGV5IHdlcmUgb3BlbmluZyB1cCBwb3RlbnRpYWwgcmF0aG9sZXMgaW4g dGhlaXIgc2NvcGUgYW5kIGFscmVhZHkgdGhlcmUgaXMgYSB3aG9sZSB0aHJlYWQgZ29pbmcgb24g aGVyZSBvbiBBREQgYWJvdXQgd2hhdCBUcnVzdCBtZWFucyBpbiBhIHZhcmlldHkgb2YgY29udGV4 dHMuIEEgbG90IG9mIHRoYXQgaXMgYmVjYXVzZSB0aGUgVG9tbXkNClBhdWwgYW5kIEJlbiBTY2h3 YXJ0eiBwcm9wb3NhbHMgcHVsbGVkIGluIHdvcmsgYmV5b25kIEQmYW1wO1MgYW5kIGdvdCBpbnRv IHNvbWUgZGlzY3Vzc2lvbiBhYm91dCByZXNvbHZlciBiZWhhdmlvciBhbmQgZXZlbiBwb2xpY3kg dmlhIHRoZSBkcmFmdHMgdGhleSBtZW50aW9uZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5J4oCZbSBub3QgdHJ5aW5nIHRvIGN1cnRhaWxpbmcgYW55IG9mIHRoZXNlIG90aGVyIGRp c2N1c3Npb25zIGlmIHBlb3BsZSB3YW50IHRvIGhhdmUgdGhlbSwgYnV0IHRoZXNlIGV2ZXIgb25n b2luZyBwb3N0aW5ncyBvbiB0aGUgQUREIGxpc3QgaGF2ZSBtYWRlIHZlcnkgbGl0dGxlIHByb2dy ZXNzIHRvIG5vIHByb2dyZXNzIHRvd2FyZCByZXNvbHV0aW9uLiBNZWFud2hpbGUgd2UgaGF2ZSBF bmNyeXB0ZWQgRE5TIGRlcGxveW1lbnRzIGdvaW5nDQpvbiB0aGF0IGhhdmUgYSBjcml0aWNhbCBu ZWVkIGZvciBzY2FsYWJsZSBhbmQgcHJhY3RpY2FsIGRpc2NvdmVyeSBhbmQgc2VsZWN0aW9uLiZu YnNwOyBQdWxsaW5nIHRvbyBtdWNoIG9mIHRoYXQgaW50byB0aGUgV0cganVzdCBhZGRzIHRvIHRo ZSBxdWlja3NhbmQgdGhlIGdyb3VwIG5lZWRzIHRvIHdhZGUgdGhyb3VnaC4gVGhpcyB3aG9sZSBh cmVhIGlzIHN1Y2ggYSBicm9hZCB0b3BpYyBhcmVhIHdpdGggbm8gc2hvcnRhZ2Ugb2Ygb3Bpbmlv bnMsIHZpc2lvbiwNCm9yIGNyZWF0aXZpdHkgLSBidXQgYXQgc29tZSBwb2ludCB0aGVyZSBpcyBh IG5lZWQgdG8gZG8gdHJpYWdlIGFuZCBnZXQgYnVzeSBvbiBoaWdoZXN0IHByaW9yaXR5IG5lZWQu PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5NeSBwcm9wb3NhbCB3YXMgc2ltcGx5IHRv IGJyZWFrIHRoZSBsb2cgamFtIGFuZCBnZXQgc29tZSByZWFsIHdvcmsgPC9kaXY+DQo8ZGl2PnN0 YXJ0ZWQuJm5ic3A7Jm5ic3A7IElmIHRoZSBBRHMgd2FudCB0byBleHBhbmQgdGhlIFdHIHNjb3Bl IGF0IGFueXRpbWUgZWl0aGVyIGRheSA8L2Rpdj4NCjxkaXY+MSBvciBkYXkgMTAwIG9mIHRoZSBX R+KAmXMgbGlmZSwgYXMmbmJzcDsgVGVkIEwuIHBvaW50ZWQgb3V0IGVhcmxpZXIgdG9kYXksIHRo ZXkmbmJzcDsgY2FuLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWxsIDMgcHJvcG9z YWxzIGhhdmUgZ29vZCBib25lcyBpbiBteSBvcGluaW9uLCBidXQgSSBiZWxpZXZlIHRoYXQgdGhl IGdyb3VwIHdpbGwgYmUgcHJpbWVkIGZvciBhIGhpZ2hlciBjaGFuY2Ugb2Ygc3VjY2VzcyBpZiBp dCBjYW4gc3RhcnQgYnkgbm90IHRyeWluZyB0byBiaXRlIG9mZiB0b28gYmlnIGEgZmlyc3QgYml0 ZS4gV2hhdGV2ZXIgcHJvcG9zYWwgaXMgUkVW4oCZZCB0byBwcm9kdWNlIGEgd29ya2FibGUgY2hh cnRlciBpcyBmaW5lLiZuYnNwOw0KSSBldmVuIHBvc3RlZCBhbiBlZGl0ZWQgdmVyc2lvbiBvZiB0 aGUgUGF1bHkgcHJvcG9zYWwgYSBsaXR0bGUgZWFybGllciBpbiByZXNwb25zZSB0byBUZWTigJlz IHF1ZXN0aW9uIG9mIGhvdyBJIHdvdWxkIGVkaXQgdGhhdCBwcm9wb3NhbC48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PkFzIGZvciBjb21tZW50cyByZWNlaXZlZDogSeKAmWxsIG5vdGUg dGhhdCB3aGlsZSB0aGVyZSBoYXZlIGJlZW4gcG9zdHMgYXNzZXJ0aW5nIHRoYXQgdGhleeKAmWQg bGlrZSBYIG9yIFkgaW5jbHVkZWQsIG9yIGluIG9uZSBjYXNlIHRoYXQgdGhleeKAmWQgd2FudCB0 byBzZWUgREhDUCBleGNsdWRlZCwgdGhlcmUgaGF2ZSBhbHNvIGJlZW4gYSBjb3VwbGUgb2YgcG9z dHMgaW4gc3VwcG9ydCBvZiB3aGF0IEkgd3JvdGUgYW5kIHdoaWxlIHNvbWUgc2FpZA0KaXQgbWF5 IG5vdCBpbmNsdWRlIGV2ZXJ5dGhpbmcgdGhleSBtaWdodCB3YW50IC0gdGhleSBjb3VsZCBsaXZl IHdpdGggaXQgYXMgYSBzdGFydC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkJlaW5n IHJlYWxpc3RpYywgZXZlbiBsaW1pdGluZyB0aGUgd29yayB0byBEaXNjb3ZlcnkgYW5kIFNlbGVj dGlvbiBnaXZlcyB0aGUgV0cgYSBsb3Qgb2Ygd29yayB0byBkbywgYW5kIGhhcmQgd29yayBhdCB0 aGF0LiZuYnNwOyBXZSBhbHJlYWR5IGhhdmUgZGlmZmVyZW50IEQmYW1wO1MgYXBwcm9hY2hlcyBi ZWluZyBwdXQgb24gdGhlIHRhYmxlIHRoYXQgd2hlbiB5b3UgZGlnIGludG8gdGhlbSBhcmUgcHJl dHR5IGZhciBhcGFydCBhbmQgdGhlIFdHIGhhc27igJl0DQpldmVuIG9wZW5lZCBpdHMgZG9vciBm b3IgZHJhZnQgc3VibWlzc2lvbnMuJm5ic3A7IFByb3Bvc2FscyByYW5nZSBmcm9tIHRoZSBjbGll bnQgZ2V0dGluZyB0aGUgaW5mbyBmcm9tIHRoZSBuZXR3b3JrOyBmcm9tIGEgZG9tYWluIGNvbW11 bmljYXRpbmcmbmJzcDsgd2hhdCB0aGUgRE5TIHNlcnZpY2VzIGl0IHJlY29tbWVuZHM7IGNsZXZl ciBhcHBsaWNhdGlvbnMgb2YgRE5TU0VDOyBzb21lIGFkdm9jYXRpbmcgYXBwbGljYXRpb25zIG9m IERIQ1A7IGFuZCBvdGhlcnMuJm5ic3A7DQpXZSBhbHNvIGFscmVhZHkgaGF2ZSBhIGNsaWVudCBk ZXBsb3llZCBpbiB0aGUgd2lsZCB0aGF0IGNvbWVzIHdpdGggdGhlIGxpc3QgYnVpbHQgaW50byB0 aGUgY2xpZW50IHdoaWNoIHRoZW4gY29tYmluZXMgdGhhdCB3aXRoIHRoZSBjbGllbnRzIGN1cnJl bnQgRE5TLzUzIHNldHRpbmdzIHRvIG1ha2UgaXRzIGRlY2lzaW9uLiBTbyBubyBzaG9ydGFnZSBv ZiBhcHByb2FjaGVzLiZuYnNwOyBUaGlzIGlzbuKAmXQgYWJvdXQgYmVpbmcgbmFycm93IHNvIGFz IHRvIHNpZGVzdGVwDQppbnRlcmVzdGluZyBwcm9wb3NhbHMgb24gaG93IHRvIGV2b2x2ZSBETlMs IGl0IGlzIGluc3RlYWQgYWJvdXQgdGFraW5nIGEgZmlyc3QgYml0ZSB0aGF0IGhhcyBhbiBhY3R1 YWwgY2hhbmNlIG9mIHByb2dyZXNzIGluIGEgcmVhc29uYWJsZSB0aW1lIGZyYW1lLjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkdsZW5uPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_LO2P265MB0573C3B9C68DD37A9A5513DDC2380LO2P265MB0573GBRP_-- From nobody Fri Jan 10 05:39:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5CA1208C6 for ; Fri, 10 Jan 2020 05:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3RBFteVLnK5 for ; Fri, 10 Jan 2020 05:39:34 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 AA7991208CC for ; Fri, 10 Jan 2020 05:39:32 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id y1so1494581lfb.6 for ; Fri, 10 Jan 2020 05:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LdByt9FKYZO8zAJ5S6zA/rlPPXZz69xNwybLSi3jQHg=; b=EyrpQGxJ8cfwa7pdmO9f+613F3z9NZo5DpNC2goYZrb0TXSRhDEC0PpfaMNVgXuYNF EaOkCaMoyVM3xCcNy3Qcmv7FW9teZSpWIDy89i10eJd847ehnFE8TLIHpYSw2IohkaOh Poi2+91VLIbUNZhjc2j44yQO7N5UtxDrJK/NdSm06SnUySH5x+YAtlbY6q7S3yi0vCOA D2VTGWerNQ2e6iYyeKpF4CXyULEF7A9tjII/SUnXfRdJcxMe8QBw6J1zXcDf0zh9Y388 li6ufjB02df8j/AHZ/Uews1hEG9w44tpl9Zzu6m7oAYgrTE6pAEyebxQlsKGPiuACpkT RU0A== 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=LdByt9FKYZO8zAJ5S6zA/rlPPXZz69xNwybLSi3jQHg=; b=n3jxQkIlBSqE1hT60nZKaMfdVTCU2DJdJnrcoCx0ZK2R5PHtmHCfJKBsU/Szu6FdbZ d4VVNc6+braEhnDsZwfz0gFDJP0TduNTIgzvCmw82K1stFfc4tDs8Ca+/Wf1us6lrBF2 s+aDRznv0F+MYLo+AgNPN1NDT74XUm9gTTjGzfsZAHieRFGemLPX2tKGgKA0Ekh5n0Ma FZseH6fpKKq0HdOSEvnkaN3Xol4T5k2+g9DgDQLbnlIaSFBGKpUgXtcGDynmWyimU0um ZE1kw2vfFWZDgr9gZisxTvGP2n3mGLbrZFlopcijnBzD6uG92KTqeL2t+mZOxwNw7y+Q so+Q== X-Gm-Message-State: APjAAAVRkFtQyfPt/4hz+OzXrKzRyHDQzUJc5zRiIInIKIZskAZnQoj2 35NKrNspCrJsg89PVydPQ4WYQpDnbol9nRIrsAcY9bk8STs= X-Google-Smtp-Source: APXvYqx5uMaiS+c1OaAHEQL7NmMFlkqlNYPivC9lbv9yK6GdtXXHy1wZBs4IdD5Z3nmFYXKimlV8We/fxB3xYjO5q8c= X-Received: by 2002:ac2:4849:: with SMTP id 9mr2396677lfy.11.1578663570876; Fri, 10 Jan 2020 05:39:30 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> In-Reply-To: <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> From: Eric Rescorla Date: Fri, 10 Jan 2020 05:38:54 -0800 Message-ID: To: Vittorio Bertola Cc: "STARK, BARBARA H" , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005cc2b9059bc941a9" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 13:39:37 -0000 --0000000000005cc2b9059bc941a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 10, 2020 at 2:38 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > Il 09/01/2020 23:01 Eric Rescorla ha scritto: > > > > > On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H < bs7652@att.com> wrote: > > There would totally be a point in implementing it. There are many > usage scenarios where the administrator or user of the device trusts (or > can determine whether they trust) a network. Just because DHCP isn=E2=80= =99t the > right solution for all scenarios, doesn=E2=80=99t mean it isn=E2=80=99t t= he right solution > for some (or even many) scenarios. If a user can be asked whether or not > the network is public or private, or the administrator can install softwa= re > that can determine if the device is on a trusted network, then the device > can use a combination of admin policy and user input to decide whether or > not to ask for / use DHCP options. Just because the DHCP option is > provided, doesn=E2=80=99t mean you have to use it. If a device doesn=E2= =80=99t use it, > we=E2=80=99re no worse off than now, with no DHCP option specified. If th= e device > does use it, then we=E2=80=99ve at least provided a solution for those us= age > scenarios where the network is trusted. Right now, we=E2=80=99re holding = =E2=80=9Cnetworks > trusted by the user/admin=E2=80=9D hostage until some convoluted solution= can be > created that adds complexity and confusion for the user and only serves t= o > shift who the user/admin has to trust (but doesn=E2=80=99t necessarily ma= ke things > more secure or private). > > > Can you explain your threat model here? If the network is trusted, then > what are you gaining by encrypting the DNS traffic? As I mentioned, there > seem to be a few edge cases where this might have some value, but I'd lik= e > to understand what it is you have in mind. > > I can't speak for Barbara, but I generally agree that encrypting the DNS > transport channel is very important if you want to connect to a faraway > public resolver over a network that you distrust, much less so if you wan= t > to connect to a local resolver over a trusted network (though an attacker > could still manage to penetrate the local network, so there is still valu= e > in it). > If the attacker penetrates the local network, they will advertise their own resolver. -Ekr > But please keep in mind that there are also strong non-technical dynamics > at play here. The web industry has (rightfully) spent years to convince > users that "encrypted =3D good, unencrypted =3D bad". As global public > resolvers go encrypted and browsers promote encrypted DNS as an important > security feature, local network administrators will also be forced to > encrypt communications with the local resolver, otherwise their users and > their boss will cry "hey, how come our resolver is still unencrypted? you > are putting us at risk!". It doesn't matter that the threat model is > different - users and management will still demand encryption for the sak= e > of encryption. > > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > --0000000000005cc2b9059bc941a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 10, 2020 at 2:38 AM Vitto= rio Bertola <vittor= io.bertola@open-xchange.com> wrote:
=20 =20 =20

Il 09/01/2020 23:01 Eric Rescorla <ekr@rtfm.com> ha scritto:




On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H < bs7652@att.com> wrote:

=C2=A0<bhs> There would totally be a p= oint in implementing it. There are many usage scenarios where the administr= ator or user of the device trusts (or can determine whether they trust) a n= etwork. Just because DHCP isn=E2=80=99t the right solution for all scenario= s, doesn=E2=80=99t mean it isn=E2=80=99t the right solution for some (or ev= en many) scenarios. If a user can be asked whether or not the network is pu= blic or private, or the administrator can install software that can determi= ne if the device is on a trusted network, then the device can use a combina= tion of admin policy and user input to decide whether or not to ask for / u= se DHCP options. Just because the DHCP option is provided, doesn=E2=80=99t = mean you have to use it. If a device doesn=E2=80=99t use it, we=E2=80=99re = no worse off than now, with no DHCP option specified. If the device does us= e it, then we=E2=80=99ve at least provided a solution for those usage scena= rios where the network is trusted. Right now, we=E2=80=99re holding =E2=80= =9Cnetworks trusted by the user/admin=E2=80=9D hostage until some convolute= d solution can be created that adds complexity and confusion for the user a= nd only serves to shift who the user/admin has to trust (but doesn=E2=80=99= t necessarily make things more secure or private).


Can you explain your threat model here? If the network is trusted, th= en what are you gaining by encrypting the DNS traffic? As I mentioned, ther= e seem to be a few edge cases where this might have some value, but I'd= like to understand what it is you have in mind.
I can't speak for Barbara, but I generally agree that encrypting the= DNS transport channel is very important if you want to connect to a farawa= y public resolver over a network that you distrust, much less so if you wan= t to connect to a local resolver over a trusted network (though an attacker= could still manage to penetrate the local network, so there is still value= in it).



But please keep in mind that there are also strong non-technical dynamic= s at play here. The web industry has (rightfully) spent years to convince u= sers that "encrypted =3D good, unencrypted =3D bad". As global pu= blic resolvers go encrypted and browsers promote encrypted DNS as an import= ant security feature, local network administrators will also be forced to e= ncrypt communications with the local resolver, otherwise their users and th= eir boss will cry "hey, how come our resolver is still unencrypted? yo= u are putting us at risk!". It doesn't matter that the threat mode= l is different - users and management will still demand encryption for the = sake of encryption.
=20
--0000000000005cc2b9059bc941a9-- From nobody Fri Jan 10 06:47:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239091200FF for ; Fri, 10 Jan 2020 06:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 BT87U88e3DPi for ; Fri, 10 Jan 2020 06:47:18 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.116]) (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 AE16E1200F7 for ; Fri, 10 Jan 2020 06:47:16 -0800 (PST) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-central-1.aws.symcld.net id B8/19-19907-27E881E5; Fri, 10 Jan 2020 14:47:14 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMJsWRWlGSWpSXmKPExsWi75nTqVvYJxF n0LpPx+L/6XVsFpP+/mS0WPH6HLvFq5M72R1YPF72z2H0WLLkJ5PHrMcT2T0mP25jDmCJYs3M S8qvSGDNmHpoN3PBtfKKc2snMzUwHszsYuTiEBLYziix/2MnM4RzmFGie8t7RrjM/+OX2SCci 4wSDcfnsXYxcgI5E5gkrl9hgkjcZ5R4NHceI0iCTcBe4tK6F2BFIgLhEjsmbGcBsZkFPCQmrX wIFhcW0JOY9/MXG0SNvsSUI/NZIOwsiT9z54HZLAKqEl+efGQCsXkFYiTe7TrOCrHsM7PE0qk 3wIo4BQIlDh/bBTaIUUBW4kvjamaIZeISt57MB2uWEBCQWLLnPDOELSrx8vE/sEG8Ag9ZJE7O OsAC0RwlsfNZB9AgDqAiRYm/M50h6mUlLs3vZoSwfSU+fdnDDmFrSZzfPwtqZrZE3+EjbBC2m sTSlRugbBmJW62nwHZJCMxikbh6aR806FIk5m7cBjVITmJV70OWCYyGs5DcPQvoDGaBPImXH5 Jngf0vKHFy5hMWiBIdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjZVJRZnpGSW5iZo6uoYG BrqGhsa65rqGFgV5ilW6SXmqpbnJqXklRIlBWL7G8WK+4Mjc5J0UvL7VkEyMwzaUUsm/Zwdj2 7a3eIUZJDiYlUV7OOPE4Ib6k/JTKjMTijPii0pzU4kOMMhwcShK8ht0ScUKCRanpqRVpmTnAl AuTluDgURLhvd4LlOYtLkjMLc5Mh0idYrTkmPBy7iJmjo+rlgDJ7yBSiCUvPy9VSpy3EKRBAK QhozQPbhwsL1xilJUS5mVkYGAQ4ilILcrNLEGVf8UozsGoJMx7twdoCk9mXgnc1ldABzEBHXT njijIQSWJCCmpBqZgneYn5xy/a5tYFa98xLx2584yhhWzZT/ds64t9DZVLJGVKeF8lch9ZA5T 30cOYZ/HGpJ1i4tOe99K2bxTlWPOjbt191tlqox3mYfVZn1Zfr1mwmuvttbVV52/yGWtvnf1U oXHupu3siaYiO7PmPSt+pdDVvshi4yrf/b5Trn+r/vWnTcC53XXXzxQFvK0Zs9UXU9vpa9rtA 5Njnbl27u42Hdn8F2xnTK5zYftS150xbf8/pjn6Fhptva+zy8Wy7mFpxfVC51e/vrG4RTfTK4 zW6JrKype+tVkHb8drv17oveWl8miT/Z/tZoxR/FSuptppdnu7kVbGnqeTxZtjG+Z71FRLinr G9oxcdPebTxKLMUZiYZazEXFiQB0LMJ+hgQAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-17.tower-245.messagelabs.com!1578667629!1798367!11 X-Originating-IP: [47.73.108.137] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.44.22; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7800 invoked from network); 10 Jan 2020 14:47:13 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe02hw.internal.vodafone.com) (47.73.108.137) by server-17.tower-245.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 10 Jan 2020 14:47:13 -0000 Received: from VOEXH10W.internal.vodafone.com (47.73.211.214) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jan 2020 15:47:11 +0100 Received: from voxe06hw.internal.vodafone.com (195.232.244.51) by VOEXH10W.internal.vodafone.com (47.73.211.208) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jan 2020 15:47:11 +0100 Received: from VOEXH11W.internal.vodafone.com (47.73.211.209) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jan 2020 15:47:11 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (172.17.213.42) by VOEXH11W.internal.vodafone.com (47.73.211.215) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jan 2020 15:47:11 +0100 Received: from AM0PR05MB5730.eurprd05.prod.outlook.com (20.178.115.152) by AM0PR05MB6210.eurprd05.prod.outlook.com (20.178.114.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 10 Jan 2020 14:47:10 +0000 Received: from AM0PR05MB5730.eurprd05.prod.outlook.com ([fe80::8850:d3a3:a063:cfb7]) by AM0PR05MB5730.eurprd05.prod.outlook.com ([fe80::8850:d3a3:a063:cfb7%5]) with mapi id 15.20.2623.013; Fri, 10 Jan 2020 14:47:10 +0000 From: "Smith, Kevin, Vodafone Group" To: Eric Rescorla , Vittorio Bertola CC: ADD Mailing list , "STARK, BARBARA H" Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVt0kW/l+9dnGimkqXhkI5p91jqqfaxzeAgAL7o4CABRjOAIAACcSAgAAUwICAAAgOgIAA03sAgAAyUgCAAA8IQA== Date: Fri, 10 Jan 2020 14:47:10 +0000 Message-ID: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2020-01-10T14:47:08.9516626Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; Sensitivity=C2 General x-originating-ip: [47.73.248.188] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53f3b666-83e1-4fc6-38a7-08d795dbf8fa x-ms-traffictypediagnostic: AM0PR05MB6210: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(366004)(376002)(39860400002)(54014002)(199004)(189003)(5660300002)(186003)(9686003)(66476007)(54906003)(55016002)(6506007)(52536014)(53546011)(7696005)(316002)(110136005)(66946007)(26005)(66446008)(64756008)(66556008)(76116006)(33656002)(4326008)(8936002)(2906002)(81166006)(81156014)(478600001)(8676002)(86362001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR05MB6210; H:AM0PR05MB5730.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A8IjjqEWbRySP9sp2zMiUP7k1EmXvIpowwp0ATC/QH451+9bjjZTm16OrCtEvE5r/3Wh/1oAn1qYOvGwzA+rriP7KGGYZW6ihuUav7Q+/kp/3pYbiLODMAu3FDjOPfsK+ylp+Ck7CoJQI9FoM3gt4Xqakl+60lgaYToFyHqypfXBEQ8bJcfzry3qXHRG0YqNZoPI016cUwI4GUUA367jsRxCfD+rKYl4fcknrVda/xRcgh+H29C9Z8uzTRKSt82pCuOO3fLD8gekoCGyszxU53tdpe9rmelnFAnucfzEntT35Gk3lkG/qdP3SA0wWVP+cg0o6NaozEraBbqFx4r5QkgI1KNdIzi9ZanpB1wxonHT2KLINSQQ7wRQ59mg44CtAHsD7eN29uf+XkJ3E3M7esiOP/qhg1sW1dt2bTDqTWcFs6NhJpZ44EocI15z/jK6u2REhOlkuLVbqcj9bQy3A85rgES1Q5M5uBcEAbbtAuDPHuoCc3PzHr+nHk+4LDja x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aw+y1ljLnY7IEzham8hujpkEAHi3rBE5mGY1Hh8ANlJkStLQ2wjIBPkInKauc0mojpDS0NhdbHcJOFyHo0xMyHlSY8y8wQSeSO0+0/bHy9zwpk9z8oEB13E/ibCJ+55jPGtBRlG9M7QoUNmd5hjRw6wMJWf1W+QPXVS/xwFvMO2FXghKH9leRLTh57oo+XxZM9maRb3WteT8v+HmfR76l+uuoArpc2KFhKXxz+I5licvFlxmxv+MKnBtbB43rzKnINrsKAEQKc1T9zUMTBEIms/88UrSkf3P8ehI7HIMAkGB0tHPvZE3UIqd1I+N0i07fgpXtL+x+L5OvmCvFFGUEA== 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=gymnxnbQ3slDMSLY0RqH3NXoJvXCOaEiZDbQ6gII7JU=; b=JuIu/qKIrnHJ5Jd4WwhQO9/sqYF7ef6wOOG5F0xukzs/NKwRF6Rqz3HYdcvc/BiGOvk50pvvJ23H+4nevazbObWrUT606Lzys+woEIwt7IJT5S9b2mkFpuz9HrwSYlQrlWYrH9ROywsLD4HFwfufPCagCJpyUCBUiZUhMEP+K4SqueLkLLRdOep/oKSZxHCYKlHT+AP0UIheXC2zmD0oofozBS7KlfIw3DbJ1+xqzVFa1nnYs4CwHnd4f9sY/XY1RrtXuuiUvCxW+16P7Wa4eEREdhNAJN9P9S9tedeaXb8+6T+OTWrYQfqqAaZQy8d2Bw3hP0TgET8Yeik0SO15Sw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vodafone.com; dmarc=pass action=none header.from=vodafone.com; dkim=pass header.d=vodafone.com; arc=none x-ms-exchange-crosstenant-network-message-id: 53f3b666-83e1-4fc6-38a7-08d795dbf8fa x-ms-exchange-crosstenant-originalarrivaltime: 10 Jan 2020 14:47:10.3009 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: vOWmXsHVrO0Z6DXa8LZZKKiDXYKyXq7u4bhmmOfeCOd5V3MUxzDN1TTfNDNjtSCnBJvZ8vQwNVejqhiu3YXFnwgtbbGpzOuCXxO54twdyNM= x-ms-exchange-transport-crosstenantheadersstamped: AM0PR05MB6210 Content-Type: multipart/alternative; boundary="_000_AM0PR05MB5730D60E4A3D792231F31DC091380AM0PR05MB5730eurp_" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 14:47:22 -0000 --_000_AM0PR05MB5730D60E4A3D792231F31DC091380AM0PR05MB5730eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > If the attacker penetrates the local network, they will advertise their o= wn resolver. That's certainly a valid threat. Seems like it could be mitigated by a clie= nt's Trusted Resolver table storing the pre-configured IP address for a giv= en network's resolver - although that may result in a failure if that IP ha= s changed for some reason. Is there another mechanism to authenticate local= network recursive resolvers at the point of advertisement, and hence disti= nguish them from a rogue resolver in that network? All best, Kevin From: Add On Behalf Of Eric Rescorla Sent: 10 January 2020 13:39 To: Vittorio Bertola Cc: ADD Mailing list ; STARK, BARBARA H Subject: Re: [Add] A proposed charter for ABCD On Fri, Jan 10, 2020 at 2:38 AM Vittorio Bertola > wrote: Il 09/01/2020 23:01 Eric Rescorla > ha sc= ritto: On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H < bs7652@att.com> wrote: There would totally be a point in implementing it. There are many us= age scenarios where the administrator or user of the device trusts (or can = determine whether they trust) a network. Just because DHCP isn't the right = solution for all scenarios, doesn't mean it isn't the right solution for so= me (or even many) scenarios. If a user can be asked whether or not the netw= ork is public or private, or the administrator can install software that ca= n determine if the device is on a trusted network, then the device can use = a combination of admin policy and user input to decide whether or not to as= k for / use DHCP options. Just because the DHCP option is provided, doesn't= mean you have to use it. If a device doesn't use it, we're no worse off th= an now, with no DHCP option specified. If the device does use it, then we'v= e at least provided a solution for those usage scenarios where the network = is trusted. Right now, we're holding "networks trusted by the user/admin" h= ostage until some convoluted solution can be created that adds complexity a= nd confusion for the user and only serves to shift who the user/admin has t= o trust (but doesn't necessarily make things more secure or private). Can you explain your threat model here? If the network is trusted, then wha= t are you gaining by encrypting the DNS traffic? As I mentioned, there seem= to be a few edge cases where this might have some value, but I'd like to u= nderstand what it is you have in mind. I can't speak for Barbara, but I generally agree that encrypting the DNS tr= ansport channel is very important if you want to connect to a faraway publi= c resolver over a network that you distrust, much less so if you want to co= nnect to a local resolver over a trusted network (though an attacker could = still manage to penetrate the local network, so there is still value in it)= . If the attacker penetrates the local network, they will advertise their own= resolver. -Ekr But please keep in mind that there are also strong non-technical dynamics a= t play here. The web industry has (rightfully) spent years to convince user= s that "encrypted =3D good, unencrypted =3D bad". As global public resolver= s go encrypted and browsers promote encrypted DNS as an important security = feature, local network administrators will also be forced to encrypt commun= ications with the local resolver, otherwise their users and their boss will= cry "hey, how come our resolver is still unencrypted? you are putting us a= t risk!". It doesn't matter that the threat model is different - users and = management will still demand encryption for the sake of encryption. -- C2 General Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy --_000_AM0PR05MB5730D60E4A3D792231F31DC091380AM0PR05MB5730eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> If the attacker penetrates the local network, they will advertise th= eir own resolver.

 = ;

That’= ;s certainly a valid threat. Seems like it could be mitigated by a client&#= 8217;s Trusted Resolver table storing the pre-configured IP address for a given network’s resolver – although that may res= ult in a failure if that IP has changed for some reason. Is there another m= echanism to authenticate local network recursive resolvers at the point of = advertisement, and hence distinguish them from a rogue resolver in that network?

 = ;

All best,<= o:p>

Kevin=

 = ;

 = ;

 = ;

From: = Add <add-bounces@ietf.org> On Behalf Of Eric Rescorla
Sent: 10 January 2020 13:39
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Cc: ADD Mailing list <add@ietf.org>; STARK, BARBARA H <bs76= 52@att.com>
Subject: Re: [Add] A proposed charter for ABCD

 

 

 

On Fri, Jan 10, 2020 at 2:38 AM Vittorio Bertola <= ;vittorio.bertola@open= -xchange.com> wrote:

 

Il 09/01/2020 23:01 Eric Rescorla <ekr@rtfm.com> ha scritto:

 

 

 

 

On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H <= bs7652@att.com> wrote:

 <bhs> There would totally be a point in implementing i= t. There are many usage scenarios where the administrator or user of the de= vice trusts (or can determine whether they trust) a network. Just because DHCP isn’t the right solution for all scenar= ios, doesn’t mean it isn’t the right solution for some (or even= many) scenarios. If a user can be asked whether or not the network is publ= ic or private, or the administrator can install software that can determine if the device is on a trusted network, then the device = can use a combination of admin policy and user input to decide whether or n= ot to ask for / use DHCP options. Just because the DHCP option is provided,= doesn’t mean you have to use it. If a device doesn’t use it, we’re no worse off than now, with = no DHCP option specified. If the device does use it, then we’ve at le= ast provided a solution for those usage scenarios where the network is trus= ted. Right now, we’re holding “networks trusted by the user/admin” hostage until some convoluted solution can be create= d that adds complexity and confusion for the user and only serves to shift = who the user/admin has to trust (but doesn’t necessarily make things = more secure or private).

 

Can you explain your threat model here? If the netwo= rk is trusted, then what are you gaining by encrypting the DNS traffic? As = I mentioned, there seem to be a few edge cases where this might have some v= alue, but I'd like to understand what it is you have in mind.

I can't speak for Barbara, but I generally agree tha= t encrypting the DNS transport channel is very important if you want to con= nect to a faraway public resolver over a network that you distrust, much le= ss so if you want to connect to a local resolver over a trusted network (though an attacker could still mana= ge to penetrate the local network, so there is still value in it).

 

If the attacker penetrates the local network, they w= ill advertise their own resolver.

 

-Ekr

 

 

But please keep in mind that there are also strong n= on-technical dynamics at play here. The web industry has (rightfully) spent= years to convince users that "encrypted =3D good, unencrypted =3D bad= ". As global public resolvers go encrypted and browsers promote encrypted DNS as an important security feature, local= network administrators will also be forced to encrypt communications with = the local resolver, otherwise their users and their boss will cry "hey= , how come our resolver is still unencrypted? you are putting us at risk!". It doesn't matter that the threat model= is different - users and management will still demand encryption for the s= ake of encryption.

--

 

= C2 General

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittor=
io.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, =
Italy
--_000_AM0PR05MB5730D60E4A3D792231F31DC091380AM0PR05MB5730eurp_-- From nobody Fri Jan 10 06:47:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9AE12016E for ; Fri, 10 Jan 2020 06:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, 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 qX2ogV_5wG95 for ; Fri, 10 Jan 2020 06:47:50 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8BF1200F7 for ; Fri, 10 Jan 2020 06:47:49 -0800 (PST) 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 053E16A28D; Fri, 10 Jan 2020 15:47:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1578667667; bh=DY8ccf+gsQmdssUF1W3H9+6fX92F6CaXiAg6UxSa55k=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=1UyJZLCNSFjzldiT57aZaZX3Mh89kf3rmKLA5zZL9hutR95ZUxvJUsLudM40gGl/d 5b6vdNao1sDJXBFtK5AKx19YHcc7kk7AqkkRCamxXPWXPbTG2oOcqwfjgwvwN0A3RK iCw2YcUuxxGfqVWZMKo4ZaP+nJi7Ai6QNHUGJa+/8t7K0VnkUst1MaagLf18dxh33G EyP4zG5Ia4jjiQ8kFFe3vkF0VhlS5Z680wW7JLHCAyPXrOMTy680aCmgznkV5eAMt6 njah6ivulyMIGPASbtgK+tjrdv1zvcA1RxTQyO+yWcAq5RFlPo0i3dzXhurrb2Gn5n w4qLFlwJeaxLQ== 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 DE27B3C03B4; Fri, 10 Jan 2020 15:47:46 +0100 (CET) Date: Fri, 10 Jan 2020 15:47:46 +0100 (CET) From: Vittorio Bertola To: Eric Rescorla Cc: ADD Mailing list , "STARK, BARBARA H" Message-ID: <1358238778.25546.1578667666816@appsuite-gw2.open-xchange.com> In-Reply-To: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.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.3-Rev3 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] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 14:47:53 -0000 =20 =20

Il 10/01/2020 14:38 Eric Rescorla <ekr@rtfm.com> ha scritto:




On Fri, Jan 10, 2020 at 2:38 AM Vittorio Bertola < vittorio.bertola= @open-xchange.com> wrote:

Il 09/01/2020 23:01 Eric Rescorla < ekr@rtfm.com> ha scritto:




On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H <=20 bs7652@att.com> wrote:=20

 <bhs> There would totally b= e a point in implementing it. There are many usage scenarios where the admi= nistrator or user of the device trusts (or can determine whether they trust= ) a network. Just because DHCP isn=E2=80=99t the right solution for all sce= narios, doesn=E2=80=99t mean it isn=E2=80=99t the right solution for some (= or even many) scenarios. If a user can be asked whether or not the network = is public or private, or the administrator can install software that can de= termine if the device is on a trusted network, then the device can use a co= mbination of admin policy and user input to decide whether or not to ask fo= r / use DHCP options. Just because the DHCP option is provided, doesn=E2=80= =99t mean you have to use it. If a device doesn=E2=80=99t use it, we=E2=80= =99re no worse off than now, with no DHCP option specified. If the device d= oes use it, then we=E2=80=99ve at least provided a solution for those usage= scenarios where the network is trusted. Right now, we=E2=80=99re holding = =E2=80=9Cnetworks trusted by the user/admin=E2=80=9D hostage until some con= voluted solution can be created that adds complexity and confusion for the = user and only serves to shift who the user/admin has to trust (but doesn=E2= =80=99t necessarily make things more secure or private).


Can you explain your threat model here? If the network is truste= d, then what are you gaining by encrypting the DNS traffic? As I mentioned,= there seem to be a few edge cases where this might have some value, but I'= d like to understand what it is you have in mind.
I can't speak for Barbara, but I generally agree that encrypting th= e DNS transport channel is very important if you want to connect to a faraw= ay public resolver over a network that you distrust, much less so if you wa= nt to connect to a local resolver over a trusted network (though an attacke= r could still manage to penetrate the local network, so there is still valu= e in it).=20

If the attacker penetrates the local network, they will advertise the= ir own resolver.
This depends on how and to which extent they penetrate; they could be in= the position to sniff unencrypted DNS traffic, but not to advertise a reso= lver. But even if they were, there could be ways to develop a strengthened = discovery mechanism that counters that attack; trust on first use is consid= ered good enough for MTA-STS, Expect-CT is good enough for website certific= ates, why couldn't we come up with something good enough to detect unauthor= ized DoH resolver change/impersonation on local networks in most reasonable= cases?

-- 

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 Fri Jan 10 06:53:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF341200B7 for ; Fri, 10 Jan 2020 06:53:24 -0800 (PST) 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_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=gTsnxjct; dkim=pass (2048-bit key) header.d=comcast.com header.b=Ldqgewee; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=UvGcA5jx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyaYaWHRtJON for ; Fri, 10 Jan 2020 06:53:20 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 1A1C312001E for ; Fri, 10 Jan 2020 06:53:19 -0800 (PST) Received: from pps.filterd (m0156896.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00AEkNAG006925 for ; Fri, 10 Jan 2020 09:53:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=l1bBki1BaolAnJ4JM5wojtI2dBMRlCDFuk4yoYpsf9A=; b=gTsnxjct9FbWy6daWFUaQstzMuIPkGZECuvl2qpyzFbGX3vU56fc+xm1cTWyL5HPkgnJ U6WbToH/m3CHV9u6kh616hSmjeI6n8BRQhtH2tbjAgZOWr8n6tmPHgveIMk5grVLSHWz m4aRXGMfv7Vuf2mAS93XvMvIllFDR6+6CljE6qNwX9/OKvbnCXny9qBEZEn0l+Qoaqp8 n/U+HxCdglmQUeXo8eh5HTzdwEGX13Qn8lkcGqQgXZqXNNG1qp6CanLyuJ01j+tUkvmH qjWJnz68c062DpY1pbhTjzV5rjcLUux6wvxV6H//bV4jvfNczlz1iESFoRbEYUb1EboS cw== Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) by mx0b-00143702.pphosted.com with ESMTP id 2xeajx59rn-31 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 10 Jan 2020 09:53:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1578667998; x=2442581598; 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=l1bBki1BaolAnJ4JM5wojtI2dBMRlCDFuk4yoYpsf9A=; b=LdqgeweejSYPPJts1tIDdtz5clrKjOCO9eNBNZvEZSPmiFhtrbyuUVQqSxHLCVqB mijaj5uM7inRv6lk389j+4Ct+NGv7wun99iEh4STlhFki9zX7N5/U+u5nvQO9PCI EM/JY9RWcWa3BLyIbfQt4HYFLHp+aC2vWMFTc97KquDFPQ64fia8A2NGyco7EY62 7ppwyikPD9hQMuFpbFekwcb/yVteoyU1UeI4VI3obL78neMI5QOWu0PPUtV5Tge9 QpR59BdhEJ6a14WufAMCdgnsnTz/3H10yE/dLupyBxbDlUGpTWU4Z41U+cSijQSG 3LhFCjjpt3sTHTvA5Zr22w==; X-AuditID: 60721c4c-831ff70000006b6a-f2-5e188fdd2d3d Received: from PACDCEX24.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 vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id A3.B4.27498.DDF881E5; Fri, 10 Jan 2020 09:53:18 -0500 (EST) Received: from PACDCEX39.cable.comcast.com (24.40.2.138) by PACDCEX24.cable.comcast.com (24.40.1.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 09:53:16 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX39.cable.comcast.com (24.40.2.138) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 10 Jan 2020 09:53:16 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.106) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 Jan 2020 09:53:07 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Fri, 10 Jan 2020 14:53:06 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.011; Fri, 10 Jan 2020 14:53:06 +0000 From: "Livingood, Jason" To: ADD Mailing list Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVx6IkqBx1on+MFkGbIM7jEmyOcKfj51UA///A6IA= Date: Fri, 10 Jan 2020 14:53:06 +0000 Message-ID: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2601:41:200:4600:8193:e66:4a0:6a94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a331b4ce-c5e6-4e02-581e-08d795dcccfd x-ms-traffictypediagnostic: BN6PR1101MB2195: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(136003)(366004)(39860400002)(189003)(199004)(81156014)(66574012)(81166006)(76116006)(8676002)(2616005)(2906002)(316002)(4744005)(5660300002)(6916009)(186003)(478600001)(91956017)(6506007)(8936002)(86362001)(66446008)(66946007)(6512007)(6486002)(33656002)(66556008)(71200400001)(66476007)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2195; H:BN6PR1101MB2195.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: HqO+XKnoKXaT2tv0Jz3MTHct83jX+St4Iych52tYAmqsMr1EEU6JQ5DU+Q1mqEnb5GcuI0sAScjpKWuNCPg/p7KgnYG1xBvRf0JwJq6IY3qX/nbzrHzMSsBFGGiOHWgnSsY7xryGLUCsjC54RXAcRngAprlIX7oblyBeNmY3ifwXnOf51eK5T8cJS1h07KdRsLN5lSmQwebgUlpLHyVbEEUkFvVOn0r9PznjJnzj+G+ThXhbAJ/fugKJQoJTdCONVYn26n+6vFLX5e9PCJ/bQkYMRb/l9gQRo6r/7pjjdjweu7FeE09iDpDMAhFgCSPJkRZ8B4uhn7iI9ZhTkXfHCRDm71Yr65pRKRm4hkjaE8076F4+SIUgWuQ0lUeV4BgIdCSbOmeiPz5MhN43r4SzV46gLMAUEOsZyFoovBqm5upXC4YFPLt+DBIZcdiKtUg+ x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N+vlk6hs5Erj+ZVkLmSrXeNBT2Ylmj5pEXmkuTEmP7PyZhvEDG9ls2cdVS5WWMkT5nGJnzIcHevqcXeDWnxlLdVAKtZndaX/pR60/E4grauzJLtbT9K4cUwhy6+oybwM9XpxWdA5p8mZdS/4HXD76+GRJnjily6QyJ4LBbEzU+9mcX4HE87WKTxtgjjVBSuglEYLwveTFOs92+djNcSQBuBwUVYPTRN1WxQLFvmTdbnmT7d9aaP0+z5n80lddJtQHUUOgtYk1S4bT4nbl8xxRtuD/f+ih7nWPqsWAAuf9MNGvtYuGfG7p/kvyyQEBpncV3xUxTTsCaMlDAr6fv6R7A== 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=xVNcbVUgVNpgF9WXlHO5ej0aZFfLRgAjGt/451wjS6g=; b=Fubc3qcXXSU7iZe6mVMPjMmcsua0P2/Qb7923lQgw6Fqx311xDWHn7ySnP4QllIR2Z1UCGAvDK2vle1tE0Yer3ntJ0oROPp85MHq+EXElUqoK93JkzHBHEVgmr1+MS+OVy3IEo5g/hC4IubFoNukBZBfthj+pMLjWWxOda5ggNgET8JvXnwLW+6hsyUMiDZFMH0cnfvytuo62QaxBO45bLUVVp6GhWQyUtauehfCmP+h870LJA0Ib274NwlsWciuGm+zlGdHy4lWI1h4Q6rRcNoUQPR/l3lDQ+1AB095No8Nfm79AGxJPcmTY5allstAlWZqKbLPjFVK4G3TJqvLMA== 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=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xVNcbVUgVNpgF9WXlHO5ej0aZFfLRgAjGt/451wjS6g=; b=UvGcA5jxgbokx75eKHQZx65mzl+kXGLgWM8sFl8m3ejqiJvnFG7GV4fB7/brt88fQaGGDIqbMjrTC4X6aG+z/+32v8L8T2HHvgGWGFt79JofuWEtAMMHFy4/+lv55h4VHXsetWP6wxNKTSeE5TRPwyEET5lMuQqb/hcEVCwU+zo= x-ms-exchange-crosstenant-network-message-id: a331b4ce-c5e6-4e02-581e-08d795dcccfd x-ms-exchange-crosstenant-originalarrivaltime: 10 Jan 2020 14:53:06.0223 (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: 3Ow3teYSaTfpNSx7um4b/ynasvVaG0sUH0Y8m09spGED3WDAHxnAJ7JApFUhXOde+dUnEB2Gvn60flB0a5KVimbQcxeHok0fMvb5zj/EGk0= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2195 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <7C21098860F6544D9CC0D4D472F6DCAA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMKsWRmVeSWpSXmKPExsWSUOxpoXuvXyLO4MJFJYv/p9exOTB6LFny kymAMaqB0aYkoyg1scQlNS01rzjVjksBA9gkpablF6W6JhblVAal5qQmYlcGUpmSmpNZllqk j9UYfazmJHQxZVw4Np+x4AVLxZ45+9gaGG+wdDFyckgImEg0XWll6mLk4hASOMgkcWr3DDaQ hJDALkaJ/9PqIRJXGSWmrnzACJE4BpQ4mACRmM4k0fbpBDOE84hR4u2Xk2DtbAJmEncXXmEG sUUElCWW3t3OBGILC+hJbJ47lQUiri8x5ch8KNtKYs6Mh6xdjBwcLAKqEr9fmIOEeQVcJCbP 2sgIMf8Xs8SH1QfBruAUCJQ4fGwX2C5GATGJ76fWgM1nFhCXuPVkPhPEbwISS/acZ4awRSVe Pv7HCmKLAu19dnMHC0RvisTirkVQ9WYS77tboeplJS7N72aEsH0lzr34DlWjI3FhyXJ2CDtf 4nfbLagaNYnt185D1chI3Go9xQpytIRAA4vE5cdn2EEeExLIknh71Q6iRk5iVe9DlgmMJrOQ nD0LqIpZQFNi/S59iLCHxOzmCewQtqLElO6HYDavgKDEyZlPWBYwsq5i5LE00zM0NNEzstAz N9vECEqKRTI+Oxg/TfM4xCjAwajEw5vbIBEnxJpYVlyZe4hRgoNZSYT36A2xOCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8We//xAoJpCeWpGanphakFsFkmTg4pRoYLWXDTQLNs5239/DZvLL+ cn2+Wd+za1ObWj9afprOHXlmr2GQuuDd3TrXK9jufZqZcTZDrCfu+4RXDP0z46VmnPf+v6Sy WLp+54VA75cXtk1OeGndc30Ce2phZex1uXouxYrGdtXHmxSNTbfUyvuXWHSHL3FbcdUp5m72 xF/iy1ne/PlStFBViaU4I9FQi7moOBEAWfipRoYDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-10_01:2020-01-10, 2020-01-09 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 14:53:24 -0000 PklmIHRoZSBhdHRhY2tlciBwZW5ldHJhdGVzIHRoZSBsb2NhbCBuZXR3b3JrLCB0aGV5IHdpbGwg YWR2ZXJ0aXNlIHRoZWlyIG93biByZXNvbHZlci4NCg0KW0pMXSBJdCBkZXBlbmRzLiBTdXJlbHkg dGhlcmUgYXJlIG1hbnkgY2FzZXMgb2YgbWFsd2FyZSBjaGFuZ2luZyB0aGUgcmVzb2x2ZXIuIFRo ZXJlIGhhdmUgYWxzbyBiZWVuIGNhc2VzIHdoZXJlIHRoZSBvcmlnaW5hbCByZXNvbHZlciBjYWNo ZSBpcyBwb2lzb25lZCBvciBldmVuIHdoZXJlIHRoZSBhdHRhY2tlcidzIG9iamVjdGl2ZSBpcyBt ZXJlbHkgdG8gcGFzc2l2ZWx5IG9ic2VydmUgdHJhZmZpYyBmb3Igd2hhdGV2ZXIgcmVhc29uLiBG b3IgbWUsIEkgaG9wZSB0aGF0IHdlIGtlZXAgZ29pbmcgaW4gdGhlIGRpcmVjdGlvbiBvZiBlbmNy eXB0aW5nIGFsbCBkYXRhIGluIHRyYW5zaXQgYXMgYSBnZW5lcmFsIHJ1bGUuDQoNCg== From nobody Fri Jan 10 06:54:13 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101B312009E for ; Fri, 10 Jan 2020 06:54:11 -0800 (PST) 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=mad.paris header.b=S37t5SoC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Of9ojCdO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzZKzRkaHLP7 for ; Fri, 10 Jan 2020 06:54:08 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA3D12001E for ; Fri, 10 Jan 2020 06:54:08 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id CA85B64E; Fri, 10 Jan 2020 09:54:06 -0500 (EST) Received: from imap26 ([10.202.2.76]) by compute3.internal (MEProxy); Fri, 10 Jan 2020 09:54:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mad.paris; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=9ViaHTS4tAXCgbmB6d2AoE4Gn/eHbSL dXmac0e3S64M=; b=S37t5SoCBu8titvcbLzS5Hj6CRghrH21gd21nZTNY/opUMc MnjPwiOp4AK8b9yHs0DlBYrGlDJlFqGIjfgvwI8EEpKZx1i/EQ+qBd8O5aVivjXV Vw6iB8UPqUYMveq1yPuTQqeEjmi80TqjXiKY4tPvMAeILhco1kUwbfuQ546EePU6 +uPciAXd/7rKE2nwjMAYRkHlxzA2icCaV/x8zMUUbT4S9hbSYDqW/XQRUgmo2cr0 3qwhL3kgN/j+bABr/+3YC5FNoNykKV4bIf14yOqSjbgn9sfA3x5K7mGIQgySJDPk w3Z2cfA2I3IoSRYFmB3VDtUt4GDLPq0aIYhZNRw== 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=9ViaHT S4tAXCgbmB6d2AoE4Gn/eHbSLdXmac0e3S64M=; b=Of9ojCdOK1mMERa52hf7ad /32q4pyaAfG7RZzghFGAywdA4yn8E/fR5wuw2mt9dQ8tl94ezoq87XySpNYz1tsH uGyrvY+02q5gwx2Khltw3z82SHnwPnBKI5Of/9+AJ9JZJjZdei3q0uOGgeGTDfQx PL7Nyv0yTZ3JedjeasI/7+LeOg/7XPOAbAw/4UjeZZbckUh4DqoouCy1inSLaMX8 NM9hLxUiZgDfoivCw7DosaWo4qyGqx0+Pj1V0eMUPX0gRzC2/tJVA6DGpaditjyk d3saLSQFWHe71MkrsuCo89zsaZwpw39b9py/NcPKtLCRzxPr+PHqS0AiTv6JBJ1A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeifedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfkfgrnhcuofgrugguihhsohhnfdcuoehirghnsehmrggu rdhprghrihhsqeenucfrrghrrghmpehmrghilhhfrhhomhepihgrnhesmhgrugdrphgrrh hishenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0D57814200A2; Fri, 10 Jan 2020 09:54:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-740-g7d9d84e-fmstable-20200109v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <7D42F41F-D47D-470F-8A8E-B58B8AE06AF9@kuehlewind.net> References: <7D42F41F-D47D-470F-8A8E-B58B8AE06AF9@kuehlewind.net> Date: Fri, 10 Jan 2020 15:53:38 +0100 From: "Ian Maddison" To: "Mirja Kuehlewind" Cc: add@ietf.org Content-Type: multipart/alternative; boundary=22129039d80b46ed91b6efb071264e6b Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 14:54:11 -0000 --22129039d80b46ed91b6efb071264e6b Content-Type: text/plain On Fri, 10 Jan 2020, at 11:35, Mirja Kuehlewind wrote: > > DNS-DS might be confusing with RFC6763 (DNS-Based Service Discovery). Yeah I thought that too. How about DNS Pick n Choose --22129039d80b46ed91b6efb071264e6b Content-Type: text/html
On Fri, 10 Jan 2020, at 11:35, Mirja Kuehlewind wrote:

DNS-DS might be confusing with RFC6763 (DNS-Based Service Discovery).

Yeah I thought that too.

How about DNS Pick n Choose

--22129039d80b46ed91b6efb071264e6b-- From nobody Fri Jan 10 07:01:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7321208FD for ; Fri, 10 Jan 2020 07:01:23 -0800 (PST) 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, 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 xUdHchnjBqPd for ; Fri, 10 Jan 2020 07:01:19 -0800 (PST) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 CA50E120898 for ; Fri, 10 Jan 2020 07:01:18 -0800 (PST) Received: by mail-pl1-x642.google.com with SMTP id f20so957791plj.5 for ; Fri, 10 Jan 2020 07:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=hWqsuxCk3TZ75dEfRqBdwgPPb31giQTTZecKZUaGFfM=; b=nlSEiLySJnpS1RLG6vsvz7H3tIOeHMPRlJBU2R5vDoJB+CfCoHji7Hj04eLmYybQT/ KjjCCzVQ9KXQ+y57b5m3DfCYDW9UloKXyvjxSu4Ep94Hh9BYctUnMo+M6DtFC0GdXu/h yxt86lT5oO/30dQTOATJvUGtUqD22l0RJufS2EOSQt4RGk0x9cqd1wvtDtJqX9RlGIkA 0MXvakvMgsowrDANaJU1G0gtEL3ZmeEfbzTMPyD+4l5kOcJ6UFXTHWBoljxX1XhtwMcI pE/1ETz831pSf7NvxkfuaqZXwDbAfotCRcc84TA6I6eAywJk2XAKfkomnlNJRFkgyGqH E92g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=hWqsuxCk3TZ75dEfRqBdwgPPb31giQTTZecKZUaGFfM=; b=McRyk51mza9VZ7ZGuAC9jioLqS1s7E/mZyYuh2h8hULCAuh2QfFTvskdDjlaWFgArE Cpy9cNGwUFaBGdPbTYt7rFXOhFENLzQZU/lQa32PttoOIBye45UFyLNBgOzICMISRABf huJE4Vd1hueO+BPdFWRx4rYLvSqzkuQiQ2SBynWe5+nu6/C0OgKoOLAYatQZdE5FI2sF t4SAUMxX/4fQMl3c1rLfQQXSkrZrUuUH7QINMxMutq8jXEvFbUyB4Zna+TiQvi8lKaq2 ZGskGZ47aKZFUuBgiNZHSVzMAr8SLeivcaD7M8m3VEFe3Dp+/BAuR1DtiLnvG4CYYcHQ qfUg== X-Gm-Message-State: APjAAAVOyAUpRhY2apZKyXKeTr6fAjeYI2bJ/NyYp/XdC4KYDau3daDy c1OjROen62ax8E3FDFynWHc1gbjjHGY= X-Google-Smtp-Source: APXvYqzR1mhHLYAifT+z67HsLdUEOg9pvYNTYNtUETZYeLnVsen4EKLC41bgb89HUkg1E97LWg5bzA== X-Received: by 2002:a17:902:b788:: with SMTP id e8mr4939326pls.1.1578668477722; Fri, 10 Jan 2020 07:01:17 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.170.45]) by smtp.gmail.com with ESMTPSA id i3sm3317018pfg.94.2020.01.10.07.01.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 07:01:16 -0800 (PST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_698AB742-31AB-40DE-90F2-DACAC08289FA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Fri, 10 Jan 2020 07:01:15 -0800 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> To: ADD Mailing list In-Reply-To: Message-Id: <8FBCE545-93A5-48F7-9698-B8EF55BBBC1F@fugue.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 15:01:28 -0000 --Apple-Mail=_698AB742-31AB-40DE-90F2-DACAC08289FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 10, 2020, at 6:47 AM, Smith, Kevin, Vodafone Group = wrote: > That=E2=80=99s certainly a valid threat. Seems like it could be = mitigated by a client=E2=80=99s Trusted Resolver table storing the = pre-configured IP address for a given network=E2=80=99s resolver =E2=80=93= although that may result in a failure if that IP has changed for some = reason. Is there another mechanism to authenticate local network = recursive resolvers at the point of advertisement, and hence distinguish = them from a rogue resolver in that network? Yes, definitely. I suspect the reason that Eric brought this up is = that there seems to be a contingent of participants in this discussion = who consider requiring that kind of validation to be too much, and would = prefer to just assume that the network is secure. > On Jan 10, 2020, at 6:47 AM, Vittorio Bertola = wrote: > This depends on how and to which extent they penetrate; they could be = in the position to sniff unencrypted DNS traffic, but not to advertise a = resolver. But even if they were, there could be ways to develop a = strengthened discovery mechanism that counters that attack; trust on = first use is considered good enough for MTA-STS, Expect-CT is good = enough for website certificates, why couldn't we come up with something = good enough to detect unauthorized DoH resolver change/impersonation on = local networks in most reasonable cases?=20 ToFU has the problem that you have to be able to securely identify the = network and tie that to the trust relationship you=E2=80=99ve = established with the network, so that you only trust that resolver when = connected to the network with which you have established trust, and = don=E2=80=99t try to use it when you are connected elsewhere (not that = there would necessarily be anything wrong with that, but it might not be = available). This is complex to specify in a way that is general enough = to be useable and yet specific enough not to ineffective. I wouldn=E2=80= =99t object to work on this, but it=E2=80=99s hard to believe that = anybody here cares enough to get this right. > On Jan 10, 2020, at 2:38 AM, Vittorio Bertola = wrote: > But please keep in mind that there are also strong non-technical = dynamics at play here. The web industry has (rightfully) spent years to = convince users that "encrypted =3D good, unencrypted =3D bad". As global = public resolvers go encrypted and browsers promote encrypted DNS as an = important security feature, local network administrators will also be = forced to encrypt communications with the local resolver, otherwise = their users and their boss will cry "hey, how come our resolver is still = unencrypted? you are putting us at risk!". It doesn't matter that the = threat model is different - users and management will still demand = encryption for the sake of encryption. This is not a non-technical dynamic. The reason the industry has done = this is not for marketing purposes. It=E2=80=99s because there are = very, very serious problems with ever downloading a web page over an = unencrypted connection. Problems that cause serious problems for = users, up to and including compromise of their financial accounts. > On Jan 9, 2020, at 5:01 PM, Andrew Campling = wrote: >=20 > I think that the reference to RFC 1958 underscores the problem in = different perspectives in this debate: the RFC pre-dates the rise of = =E2=80=9Csurveillance capitalism=E2=80=9D; the many privacy breaches by = apps (and =E2=80=9Csmart=E2=80=9D devices); and the accelerating = consolidation leading to a few corporations dominating large parts of = the Internet with the consequent loss of resilience. Therefore, the = implication of RFC 1958 that it is better to rely on the confidentiality = or integrity of endpoints rather than carriers is at best questionable = and is certainly dated. This reasoning is fallacious. There isn=E2=80=99t a tension between = securing the endpoints and securing the network. Both are good. The = fact that devices have been compromised in the past is not an argument = for not trying to ensure that devices are not compromised in the future. = Furthermore, the fact that devices have been compromised in the past = and likely will be compromised in the future is an argument _against_ = trusting the network without verification, because those compromised = devices will be attached to the network: if you trust but don=E2=80=99t = verify, those devices become an attack vector against other devices that = have not (yet) been compromised. Security tends to be compromised at the weakest link. To get more = security, protect every attack surface: don=E2=80=99t protect one attack = surface and then rely on that to allow you to relax protection on = another. --Apple-Mail=_698AB742-31AB-40DE-90F2-DACAC08289FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 10, 2020, at 6:47 AM, Smith, Kevin, Vodafone Group <Kevin.Smith@vodafone.com> wrote:
That=E2=80=99s = certainly a valid threat. Seems like it could be mitigated by a = client=E2=80=99s Trusted Resolver table storing the pre-configured IP = address for a given network=E2=80=99s resolver =E2=80=93 although that = may result in a failure if that IP has changed for some reason. Is there = another mechanism to authenticate local network recursive resolvers at = the point of advertisement, and hence distinguish them from a rogue = resolver in that network?

Yes, definitely.   I suspect the reason that = Eric brought this up is that there seems to be a contingent of = participants in this discussion who consider requiring that kind of = validation to be too much, and would prefer to just assume that the = network is secure.

On Jan 10, 2020, at 6:47 AM, Vittorio Bertola = <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> = wrote:
This = depends on how and to which extent they penetrate; they could be in the = position to sniff unencrypted DNS traffic, but not to advertise a = resolver. But even if they were, there could be ways to develop a = strengthened discovery mechanism that counters that attack; trust on = first use is considered good enough for MTA-STS, Expect-CT is good = enough for website certificates, why couldn't we come up with something = good enough to detect unauthorized DoH resolver change/impersonation on = local networks in most reasonable cases? 

ToFU has the problem that you have to be able to = securely identify the network and tie that to the trust relationship = you=E2=80=99ve established with the network, so that you only trust that = resolver when connected to the network with which you have established = trust, and don=E2=80=99t try to use it when you are connected elsewhere = (not that there would necessarily be anything wrong with that, but it = might not be available).   This is complex to specify in a way that = is general enough to be useable and yet specific enough not to = ineffective.   I wouldn=E2=80=99t object to work on this, but = it=E2=80=99s hard to believe that anybody here cares enough to get this = right.

On Jan 10, 2020, at 2:38 AM, Vittorio Bertola = <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> = wrote:
But please keep in mind that = there are also strong non-technical dynamics at play here. The web = industry has (rightfully) spent years to convince users that "encrypted = =3D good, unencrypted =3D bad". As global public resolvers go encrypted = and browsers promote encrypted DNS as an important security feature, = local network administrators will also be forced to encrypt = communications with the local resolver, otherwise their users and their = boss will cry "hey, how come our resolver is still unencrypted? you are = putting us at risk!". It doesn't matter that the threat model is = different - users and management will still demand encryption for the = sake of encryption.

This= is not a non-technical dynamic.  The reason the industry has done = this is not for marketing purposes.   It=E2=80=99s because there = are very, very serious problems with ever downloading a web page over an = unencrypted connection.   Problems that cause serious problems for = users, up to and including compromise of their financial = accounts.

On Jan 9, 2020, at 5:01 PM, Andrew Campling <andrew.campling@419.consulting> wrote:

I think that the reference to RFC 1958 underscores = the problem in different perspectives in this debate: the RFC pre-dates = the rise of =E2=80=9Csurveillance capitalism=E2=80=9D; the many privacy = breaches by apps (and =E2=80=9Csmart=E2=80=9D devices); and the = accelerating consolidation leading to a few corporations dominating = large parts of the Internet with the consequent loss of = resilience.  Therefore, the implication of RFC 1958 that it is = better to rely on the confidentiality or integrity of endpoints rather = than carriers is at best questionable and is certainly = dated.

This reasoning = is fallacious.  There isn=E2=80=99t a tension between securing the = endpoints and securing the network.  Both are good.   The fact = that devices have been compromised in the past is not an argument for = not trying to ensure that devices are not compromised in the future. =  Furthermore, the fact that devices have been compromised in the = past and likely will be compromised in the future is an argument = _against_ trusting the network without verification, because those = compromised devices will be attached to the network: if you trust but = don=E2=80=99t verify, those devices become an attack vector against = other devices that have not (yet) been compromised.

Security tends to be compromised at the weakest = link.  To get more security, protect every attack surface: don=E2=80=99= t protect one attack surface and then rely on that to allow you to relax = protection on another.

= --Apple-Mail=_698AB742-31AB-40DE-90F2-DACAC08289FA-- From nobody Fri Jan 10 08:27:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C52120914 for ; Fri, 10 Jan 2020 08:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6Ita-C-1ItCh for ; Fri, 10 Jan 2020 08:27:00 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BED12091A for ; Fri, 10 Jan 2020 08:26:59 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 347182802A6; Fri, 10 Jan 2020 17:26:57 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 2CEC22806C0; Fri, 10 Jan 2020 17:26:57 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 24E6A2802A6; Fri, 10 Jan 2020 17:26:57 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 217246A9F3A0; Fri, 10 Jan 2020 17:26:57 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 0EDCE40D35; Fri, 10 Jan 2020 17:26:57 +0100 (CET) Date: Fri, 10 Jan 2020 17:26:57 +0100 From: Stephane Bortzmeyer To: Vittorio Bertola Cc: Mirja =?utf-8?B?S8O8aGxld2luZCAoSUVURik=?= , Stephen Farrell , ADD Mailing list Message-ID: <20200110162657.GA6778@nic.fr> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:27:03 -0000 On Wed, Jan 08, 2020 at 02:06:58PM +0100, Vittorio Bertola wrote a message of 26 lines which said: > The release and early deployment of DoH opened up many non-technical > issues that need a few missing technical pieces to be addressed, I think one of the reasons why there are so many messages on this list (making it hard to follow) is that there is a fundamental disagreement at the very basis. I don't think that resolver discovery *needs* to be addressed. The whole point of DoE (DNS over Encryption) is because the user has issues with his/her access network. Therefore, *any* automatic discovery is challenging, to say the least. So, I disagree with the basic assumption that we *must* do something to enable a (possibly untrusted) network to override the choices of the end machine. > deploy encrypted DNS within the existing network architectures, > without changing the resolver operator This would defeat the main point of DoT and DoH. (Which are useful mostly when you want to use an outside resolver.) I don't think "without changing the resolver operator" should be in the requirments. > It would be kind for the IETF to work on that as soon as possible > and show to the other stakeholders that it cares about all the > complaints that have been publicly made for the last ~18 months. I don't think there is a consensus (or even a rough consensus) that these complaints are sensible. From nobody Fri Jan 10 08:30:48 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BF91209AD for ; Fri, 10 Jan 2020 08:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 iYUEUSa9kOvp for ; Fri, 10 Jan 2020 08:30:43 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297CF1209A4 for ; Fri, 10 Jan 2020 08:30:42 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C1C3C2800EB; Fri, 10 Jan 2020 17:30:40 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id B9FB92806AB; Fri, 10 Jan 2020 17:30:40 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id B1FF62800EB; Fri, 10 Jan 2020 17:30:40 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id ADFAB6A9F3A0; Fri, 10 Jan 2020 17:30:40 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id A476F3FD4B; Fri, 10 Jan 2020 17:30:40 +0100 (CET) Date: Fri, 10 Jan 2020 17:30:40 +0100 From: Stephane Bortzmeyer To: "STARK, BARBARA H" Cc: 'Ted Lemon' , 'Mirja Kuehlewind' , 'Eric Rescorla' , 'ADD Mailing list' , 'Vittorio Bertola' Message-ID: <20200110163040.GB6778@nic.fr> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.047928, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:30:45 -0000 On Wed, Jan 08, 2020 at 09:34:16PM +0000, STARK, BARBARA H wrote a message of 29 lines which said: > Why, indeed, are we encouraging a protocol that can be used by > applications to replace the resolver I and enterprise network > operators trust with one that we don't? To allow people who don't trust the access network to use a distinct resolver. > However, I do think it would be useful to see if we can come up with > a reasonable way to communicate resolver policy. Even if it's just a > url where you can indicate your privacy preferences when using that > resolver. Communicate in which direction? User to resolver ("I want this") or the opposite way ("I provide that")? From nobody Fri Jan 10 08:33:52 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60C1209DE for ; Fri, 10 Jan 2020 08:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Q8EwtMfMyNir for ; Fri, 10 Jan 2020 08:33:46 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 DF7231209DC for ; Fri, 10 Jan 2020 08:33:46 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id az3so1034676plb.11 for ; Fri, 10 Jan 2020 08:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Q4VmVNupR11XBrc1cwd9v9mck0aXI8HDR9B1Fh2GI4=; b=ZMwEmltZN65c5nkZilxGeBSSUzf5BK55Q2tzB6pKUVqmxvYNa1/Ufe6qhVxzXwhxj5 NjZ3s7sSaoybFTJDEUV6sImbNTFYBAUYCgdsP74XxiFN1bsr1wb6sx0uRRhAPGUaH6Yq mWs7sFHq+D5rhQHARD2wBTGqtIbwaXRHFNkN89aGKgyA7c+Rf92HKyg5k62+qCz4iXCO yDa7A/I4zcORvPVQiJVl7tJ8FUROZr+1q9g5SghTpUHCTWYNkaBGgOajC6AgNXe6kYJB RryCg4dpf2bGpr1SR9FC17Ty3nZb6SSi2J3y9qMk3pzo5kCAS+zA5lr387x4SbRD3m4Y BvRg== 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=5Q4VmVNupR11XBrc1cwd9v9mck0aXI8HDR9B1Fh2GI4=; b=o/IxURBfaOnyPFoyrUkA94k1aOMuwanMCey0sf/jw4Mqud6fJmp+IakH0V3YYEnC45 zqr8n3H6T0P2MHMDywh4aMCrPDWCzt9WE+/o+85CIfx7MQ8HQpV0mAtMBbMd7BNNuMDq KSpockLhr6DsPZMnpb7hdY2Bkq1o6DTaog2rhUvyjgVvmEwaSwiqqC4y9naYXnZzqi80 m6E48mMqWPEnut+gHmNMLm/LvjCI7PCcWlrfq1N4cCkGJeNbGyEiEsBke1hXUQ0gd9lN RTW8VYGVgWlKEuiJju78YNQLAkfBiCidDCDl4Kk7rRaoTOzpbVQbHID2fmUCA+SFx25S p8fg== X-Gm-Message-State: APjAAAUpNVkJfpAajMX+bBGNVdN33rDlxuGNeOzahLEAcYs8l2LhP2kZ qSnuWxj0Nu/1b+em+CnFET2xqoEHx20= X-Google-Smtp-Source: APXvYqxdtnhDRRa5j8iW0r4eJ8fQ/r60K3g1tmYSUS+ZcMYg9novbXVi9RL+EYsPLA9HS9C7LmoK5A== X-Received: by 2002:a17:902:fe0d:: with SMTP id g13mr5273113plj.277.1578674026324; Fri, 10 Jan 2020 08:33:46 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.170.45]) by smtp.gmail.com with ESMTPSA id 3sm3386081pjg.27.2020.01.10.08.33.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 08:33:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) From: Ted Lemon In-Reply-To: <20200110162657.GA6778@nic.fr> Date: Fri, 10 Jan 2020 08:33:44 -0800 Cc: Vittorio Bertola , ADD Mailing list , =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <359502E7-9010-450B-A456-B6B304D264D1@fugue.com> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <20200110162657.GA6778@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:33:50 -0000 On Jan 10, 2020, at 8:26 AM, Stephane Bortzmeyer = wrote: >> deploy encrypted DNS within the existing network architectures, >> without changing the resolver operator >=20 > This would defeat the main point of DoT and DoH. (Which are useful > mostly when you want to use an outside resolver.) I don't think > "without changing the resolver operator" should be in the requirments. DoT is useful for opportunistic security. An automatic way of deploying = it with ad-hoc trust is better than no way to deploy it with ad-hoc = trust, /as long as that mechanism doesn=E2=80=99t override a verifiable = trust relationship if one has been configured./ The reason that we are having a controversy here is that some = participants seem to want to be able to override a verifiably trusted = configuration and replace it with an ad-hoc (unverifiable) trusted = configuration. Of course no major vendor is going to implement this, = but if we were to write a standard that said to do this, I=E2=80=99m = sure that a few naive implementors here and there would implement it, to = everybody=E2=80=99s sorrow. From nobody Fri Jan 10 08:34:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9AC1209F2 for ; Fri, 10 Jan 2020 08:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8Jmo-5jTJB4R for ; Fri, 10 Jan 2020 08:34:52 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89581209DC for ; Fri, 10 Jan 2020 08:34:52 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 55C872800EB; Fri, 10 Jan 2020 17:34:51 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 4F8DF2806AD; Fri, 10 Jan 2020 17:34:51 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 47D732800EB; Fri, 10 Jan 2020 17:34:51 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 440766A9F3A0; Fri, 10 Jan 2020 17:34:51 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 38EAE3FD4B; Fri, 10 Jan 2020 17:34:51 +0100 (CET) Date: Fri, 10 Jan 2020 17:34:51 +0100 From: Stephane Bortzmeyer To: "Livingood, Jason" Cc: "STARK, BARBARA H" , 'ADD Mailing list' Message-ID: <20200110163451.GC6778@nic.fr> References: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> <5B682191-0638-4711-AE91-40D0626540B3@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B682191-0638-4711-AE91-40D0626540B3@cable.comcast.com> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.011883, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:34:54 -0000 On Thu, Jan 09, 2020 at 04:44:11PM +0000, Livingood, Jason wrote a message of 11 lines which said: > [JL] Perhaps we can simply solve the problem of how to provide a > standards-based mechanism to communicate structured data to a client > about things such as how a resolver operates (e.g. DNSSEC > validating, DoH URL of X, DOT FQDN of Y, whatever). How the app will > choose to use that information and make a selection decision seems > up to the app/OS. That's tempting (although I suspect there will be some pressures to force applications to follow blindly these signals from the access network, thus depriving the end user of a real choice, but I digress.) But isn't it already done in the PvD project? https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ From nobody Fri Jan 10 08:39:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1B2120815 for ; Fri, 10 Jan 2020 08:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 CZVDMp32C9uy for ; Fri, 10 Jan 2020 08:38:56 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFBE1200DF for ; Fri, 10 Jan 2020 08:38:56 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 35DBD2802A6; Fri, 10 Jan 2020 17:38:55 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 2FCEF2806AE; Fri, 10 Jan 2020 17:38:55 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 2818F2802A6; Fri, 10 Jan 2020 17:38:55 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 248E76A9F3A0; Fri, 10 Jan 2020 17:38:55 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 120893FD4B; Fri, 10 Jan 2020 17:38:55 +0100 (CET) Date: Fri, 10 Jan 2020 17:38:55 +0100 From: Stephane Bortzmeyer To: Glenn Deen Cc: ADD Mailing list Message-ID: <20200110163855.GD6778@nic.fr> References: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7DFF6986-A1AB-4F08-B489-CA86908DEDB4@gmail.com> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.410572, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:38:58 -0000 On Wed, Jan 08, 2020 at 03:47:50PM -0800, Glenn Deen wrote a message of 650 lines which said: > there does seem to a tremendous amount of interest in the need for > Discovery and Selection, as well as a broad and diverse set of > contributors wanting to work on it, and we have groups actually > working on building and deploying solutions as well. > > The conclusion is that there is a community of interest, > contributors, and adopters here, and the work is going to be done > somehow and somewhere The fact that people are ready to work on it is not sufficient. People were ready to work on "visibility" proposals for TLS 1.3 and IETF (rightly) refused to standardize it. From nobody Fri Jan 10 08:44:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382B91209ED for ; Fri, 10 Jan 2020 08:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 tCZBcv5xlkZf for ; Fri, 10 Jan 2020 08:44:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3F71209A3 for ; Fri, 10 Jan 2020 08:44:03 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D5F532800EB; Fri, 10 Jan 2020 17:44:01 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id CEC72280377; Fri, 10 Jan 2020 17:44:01 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id C701A2800EB; Fri, 10 Jan 2020 17:44:01 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C314F6A9F3A0; Fri, 10 Jan 2020 17:44:01 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B93A43FD4B; Fri, 10 Jan 2020 17:44:01 +0100 (CET) Date: Fri, 10 Jan 2020 17:44:01 +0100 From: Stephane Bortzmeyer To: Andrew Campling Cc: Rob Sayre , ADD Mailing list , Ted Lemon , "STARK, BARBARA H" Message-ID: <20200110164401.GE6778@nic.fr> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000005, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:44:07 -0000 On Fri, Jan 10, 2020 at 01:01:33AM +0000, Andrew Campling wrote a message of 128 lines which said: > > "Endpoints should not depend on the confidentiality or integrity > > of the carriers. Carriers may choose to provide some level of > > protection, but this is secondary to the primary responsibility of > > the end users to protect themselves." > > > RFC 1958 > Therefore, the implication of RFC 1958 that it is better to rely on > the confidentiality or integrity of endpoints rather than carriers > is at best questionable and is certainly dated. It seems to me that the RFC1958 opinion is very fundamental in all the Internet protocols (compared with, say, traditional telco protocols) and changing it is not in-scope for this list. I don't think that IETF would agree to revise this end-to-end principle. From nobody Fri Jan 10 08:46:14 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E968120A2E for ; Fri, 10 Jan 2020 08:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqE_Ho-F2KX7 for ; Fri, 10 Jan 2020 08:45:58 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADAD1209FE for ; Fri, 10 Jan 2020 08:45:51 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 4E6CC280126; Fri, 10 Jan 2020 17:45:50 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 46FB82800EB; Fri, 10 Jan 2020 17:45:50 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 3DE042800EB; Fri, 10 Jan 2020 17:45:50 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 379566A9F3A0; Fri, 10 Jan 2020 17:45:50 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 326E93FD4B; Fri, 10 Jan 2020 17:45:50 +0100 (CET) Date: Fri, 10 Jan 2020 17:45:50 +0100 From: Stephane Bortzmeyer To: Ted Lemon Cc: Stephane Bortzmeyer , Vittorio Bertola , ADD Mailing list , =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= , Stephen Farrell Message-ID: <20200110164550.GA8352@nic.fr> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <20200110162657.GA6778@nic.fr> <359502E7-9010-450B-A456-B6B304D264D1@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <359502E7-9010-450B-A456-B6B304D264D1@fugue.com> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.009476, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:46:09 -0000 On Fri, Jan 10, 2020 at 08:33:44AM -0800, Ted Lemon wrote a message of 21 lines which said: > /as long as that mechanism doesn’t override a verifiable trust > relationship if one has been configured./ Yes, this is the important thing, and it should be in any charter for a D&S WG. > Of course no major vendor is going to implement this, Canary domain in Firefox? From nobody Fri Jan 10 08:49:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D920F120A23 for ; Fri, 10 Jan 2020 08:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 XsIOND5RIFDQ for ; Fri, 10 Jan 2020 08:49:08 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4832120916 for ; Fri, 10 Jan 2020 08:48:44 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 590DA280126; Fri, 10 Jan 2020 17:48:43 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 51C162806AD; Fri, 10 Jan 2020 17:48:43 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 49E3B280126; Fri, 10 Jan 2020 17:48:43 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 45C556A9F3A0; Fri, 10 Jan 2020 17:48:43 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 3C7FC3FD4B; Fri, 10 Jan 2020 17:48:43 +0100 (CET) Date: Fri, 10 Jan 2020 17:48:43 +0100 From: Stephane Bortzmeyer To: Andrew Campling Cc: ADD Mailing list , Ted Lemon , "STARK, BARBARA H" , Rob Sayre Message-ID: <20200110164843.GA8679@nic.fr> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20200110164401.GE6778@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200110164401.GE6778@nic.fr> X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000032, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 16:49:10 -0000 On Fri, Jan 10, 2020 at 05:44:01PM +0100, Stephane Bortzmeyer wrote a message of 24 lines which said: > It seems to me that the RFC1958 opinion is very fundamental in all > the Internet protocols (compared with, say, traditional telco > protocols) and changing it is not in-scope for this list. I don't > think that IETF would agree to revise this end-to-end principle. And I forgot to mention RFC 3552, which is probably even more relevant than RFC 1958. It clearly explains that our threat model is "the network may be hostile and we cannot rely on it". From nobody Fri Jan 10 09:41:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11098120B17 for ; Fri, 10 Jan 2020 09:41:26 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 wRBv39UZujwG for ; Fri, 10 Jan 2020 09:41:25 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E638B120A81 for ; Fri, 10 Jan 2020 09:41:24 -0800 (PST) Received: from [172.16.3.98] (unknown [62.252.176.218]) (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 B4C8A2421481; Fri, 10 Jan 2020 17:41:19 +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: <20200110162657.GA6778@nic.fr> Date: Fri, 10 Jan 2020 17:41:19 +0000 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <20200110162657.GA6778@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Add] bikeshedding on the charter discussion X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 17:41:26 -0000 > On 10 Jan 2020, at 16:26, Stephane Bortzmeyer = wrote: >=20 > I think one of the reasons why there are so many messages on this list > (making it hard to follow) is that there is a fundamental disagreement > at the very basis. No. IMO the reason there are so many (somewhat off-topic) messaages is = because we're no longer discussing the charter proposals. Instead, we're = rat-holing on detail, use cases and definitions - the sorts of things = that should be getting discussed in a WG. If we had one. > I don't think that resolver discovery *needs* to be addressed. Even the question of "how to I find an encrypted DNS resolver for the = current network?"? From nobody Fri Jan 10 09:52:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13A9120B29 for ; Fri, 10 Jan 2020 09:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 pmGaC7w1hSfb for ; Fri, 10 Jan 2020 09:52:22 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 97472120AEA for ; Fri, 10 Jan 2020 09:52:22 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00AHjliS003927; Fri, 10 Jan 2020 12:52:22 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2xevxsj2ah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 12:52:21 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00AHqJmT010172; Fri, 10 Jan 2020 12:52:20 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00AHqB9n010004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jan 2020 12:52:12 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id EE8EA401466E; Fri, 10 Jan 2020 17:52:11 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30483.vci.att.com (Service) with ESMTPS id D560A4014669; Fri, 10 Jan 2020 17:52:11 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.148]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Fri, 10 Jan 2020 12:52:11 -0500 From: "STARK, BARBARA H" To: "'Eric Rescorla'" , "'Vittorio Bertola'" CC: "'ADD Mailing list'" Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVt0kQma20/9Ym9keiujEJ3hlN+afbGwiAgAL7pICABRjOAIAACcSA//+uOxCAAG6TgIAA03sAgAAyUgD//+DgwA== Date: Fri, 10 Jan 2020 17:52:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6115373E585@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.67.51] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6115373E585GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-10_01:2020-01-10, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001100144 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 17:52:25 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6115373E585GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCk9uIEZyaSwgSmFuIDEwLCAy MDIwIGF0IDI6MzggQU0gVml0dG9yaW8gQmVydG9sYSA8dml0dG9yaW8uYmVydG9sYUBvcGVuLXhj aGFuZ2UuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+PiB3cm90 ZToNCklsIDA5LzAxLzIwMjAgMjM6MDEgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0 bzpla3JAcnRmbS5jb20+PiBoYSBzY3JpdHRvOg0KT24gVGh1LCBKYW4gOSwgMjAyMCBhdCAxOjMz IFBNIFNUQVJLLCBCQVJCQVJBIEggPCBiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0dC5j b20+PiB3cm90ZToNCiA8YmhzPiBUaGVyZSB3b3VsZCB0b3RhbGx5IGJlIGEgcG9pbnQgaW4gaW1w bGVtZW50aW5nIGl0LiBUaGVyZSBhcmUgbWFueSB1c2FnZSBzY2VuYXJpb3Mgd2hlcmUgdGhlIGFk bWluaXN0cmF0b3Igb3IgdXNlciBvZiB0aGUgZGV2aWNlIHRydXN0cyAob3IgY2FuIGRldGVybWlu ZSB3aGV0aGVyIHRoZXkgdHJ1c3QpIGEgbmV0d29yay4gSnVzdCBiZWNhdXNlIERIQ1AgaXNu4oCZ dCB0aGUgcmlnaHQgc29sdXRpb24gZm9yIGFsbCBzY2VuYXJpb3MsIGRvZXNu4oCZdCBtZWFuIGl0 IGlzbuKAmXQgdGhlIHJpZ2h0IHNvbHV0aW9uIGZvciBzb21lIChvciBldmVuIG1hbnkpIHNjZW5h cmlvcy4gSWYgYSB1c2VyIGNhbiBiZSBhc2tlZCB3aGV0aGVyIG9yIG5vdCB0aGUgbmV0d29yayBp cyBwdWJsaWMgb3IgcHJpdmF0ZSwgb3IgdGhlIGFkbWluaXN0cmF0b3IgY2FuIGluc3RhbGwgc29m dHdhcmUgdGhhdCBjYW4gZGV0ZXJtaW5lIGlmIHRoZSBkZXZpY2UgaXMgb24gYSB0cnVzdGVkIG5l dHdvcmssIHRoZW4gdGhlIGRldmljZSBjYW4gdXNlIGEgY29tYmluYXRpb24gb2YgYWRtaW4gcG9s aWN5IGFuZCB1c2VyIGlucHV0IHRvIGRlY2lkZSB3aGV0aGVyIG9yIG5vdCB0byBhc2sgZm9yIC8g dXNlIERIQ1Agb3B0aW9ucy4gSnVzdCBiZWNhdXNlIHRoZSBESENQIG9wdGlvbiBpcyBwcm92aWRl ZCwgZG9lc27igJl0IG1lYW4geW91IGhhdmUgdG8gdXNlIGl0LiBJZiBhIGRldmljZSBkb2VzbuKA mXQgdXNlIGl0LCB3ZeKAmXJlIG5vIHdvcnNlIG9mZiB0aGFuIG5vdywgd2l0aCBubyBESENQIG9w dGlvbiBzcGVjaWZpZWQuIElmIHRoZSBkZXZpY2UgZG9lcyB1c2UgaXQsIHRoZW4gd2XigJl2ZSBh dCBsZWFzdCBwcm92aWRlZCBhIHNvbHV0aW9uIGZvciB0aG9zZSB1c2FnZSBzY2VuYXJpb3Mgd2hl cmUgdGhlIG5ldHdvcmsgaXMgdHJ1c3RlZC4gUmlnaHQgbm93LCB3ZeKAmXJlIGhvbGRpbmcg4oCc bmV0d29ya3MgdHJ1c3RlZCBieSB0aGUgdXNlci9hZG1pbuKAnSBob3N0YWdlIHVudGlsIHNvbWUg Y29udm9sdXRlZCBzb2x1dGlvbiBjYW4gYmUgY3JlYXRlZCB0aGF0IGFkZHMgY29tcGxleGl0eSBh bmQgY29uZnVzaW9uIGZvciB0aGUgdXNlciBhbmQgb25seSBzZXJ2ZXMgdG8gc2hpZnQgd2hvIHRo ZSB1c2VyL2FkbWluIGhhcyB0byB0cnVzdCAoYnV0IGRvZXNu4oCZdCBuZWNlc3NhcmlseSBtYWtl IHRoaW5ncyBtb3JlIHNlY3VyZSBvciBwcml2YXRlKS4NCkNhbiB5b3UgZXhwbGFpbiB5b3VyIHRo cmVhdCBtb2RlbCBoZXJlPyBJZiB0aGUgbmV0d29yayBpcyB0cnVzdGVkLCB0aGVuIHdoYXQgYXJl IHlvdSBnYWluaW5nIGJ5IGVuY3J5cHRpbmcgdGhlIEROUyB0cmFmZmljPyBBcyBJIG1lbnRpb25l ZCwgdGhlcmUgc2VlbSB0byBiZSBhIGZldyBlZGdlIGNhc2VzIHdoZXJlIHRoaXMgbWlnaHQgaGF2 ZSBzb21lIHZhbHVlLCBidXQgSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCB3aGF0IGl0IGlzIHlvdSBo YXZlIGluIG1pbmQuDQpJIGNhbid0IHNwZWFrIGZvciBCYXJiYXJhLCBidXQgSSBnZW5lcmFsbHkg YWdyZWUgdGhhdCBlbmNyeXB0aW5nIHRoZSBETlMgdHJhbnNwb3J0IGNoYW5uZWwgaXMgdmVyeSBp bXBvcnRhbnQgaWYgeW91IHdhbnQgdG8gY29ubmVjdCB0byBhIGZhcmF3YXkgcHVibGljIHJlc29s dmVyIG92ZXIgYSBuZXR3b3JrIHRoYXQgeW91IGRpc3RydXN0LCBtdWNoIGxlc3Mgc28gaWYgeW91 IHdhbnQgdG8gY29ubmVjdCB0byBhIGxvY2FsIHJlc29sdmVyIG92ZXIgYSB0cnVzdGVkIG5ldHdv cmsgKHRob3VnaCBhbiBhdHRhY2tlciBjb3VsZCBzdGlsbCBtYW5hZ2UgdG8gcGVuZXRyYXRlIHRo ZSBsb2NhbCBuZXR3b3JrLCBzbyB0aGVyZSBpcyBzdGlsbCB2YWx1ZSBpbiBpdCkuDQoNCklmIHRo ZSBhdHRhY2tlciBwZW5ldHJhdGVzIHRoZSBsb2NhbCBuZXR3b3JrLCB0aGV5IHdpbGwgYWR2ZXJ0 aXNlIHRoZWlyIG93biByZXNvbHZlci4NCi1Fa3INCg0KPGJocz4gQW55IGF0dGFja2VyIHRoYXQg ZG9lcyB0aGF0IGluIG15IGhvbWUgbmV0d29yayB3aWxsIGJlIGFibGUgdG8gY29tcHJvbWlzZSBh bGwgc29ydHMgb2YgdGhpbmdzLCBhbmQgY2FuIG1lc3MgdXAgYWRkcmVzcyBhc3NpZ25tZW50LCBu ZXh0IGhvcCByb3V0ZXIsIGV0Yy4gSWYgaXQgZG9lcyB0aGlzIGJ5IGFkdmVydGlzaW5nIGluIGFk ZGl0aW9uIHRvIG15IHJvdXRlciwgaXQgd2lsbCBhbHNvIGNhdXNlIGEgcmFjZSBjb25kaXRpb24g dGhhdCB3aWxsIG1ha2UgdGhlIG5ldHdvcmsgYmVoYXZlIGluY29uc2lzdGVudGx5IChteSB0ZXN0 aW5nIHN1Z2dlc3RzIHRoYXQgd2hhdGV2ZXIgZGV2aWNlIGFkdmVydGlzZXMgZmlyc3QsIHdpbnMp LiBPZiBjb3Vyc2UsIGlmIHRoZXkgZG8gdGhpcyBieSBjb21wcm9taXNpbmcgbXkgcm91dGVyLCB0 aGVuIEnigJl2ZSBnb3QgZXZlbiBiaWdnZXIgcHJvYmxlbXMuIFJlYWxseSB3aGF0IEkgbmVlZCBp cyBhIG1lYW5zIGZvciBkZXRlY3Rpbmcgc3VjaCBjb21wcm9taXNlcyAoc28gSSBjYW4gcmVtb3Zl IHRoZW0pLCByYXRoZXIgdGhhbiBhIG1lYW5zIHRvIHRyeSB0byBwbHVnIHVwIGV2ZXJ5IHBvc3Np YmxlIHRocmVhdCB0aGF0IG1hbHdhcmUgaW5zaWRlIHRoZSBuZXR3b3JrIHByZXNlbnRzLiBBbmQg ZGV0ZWN0aW5nIG11bHRpcGxlIERIQ1Agb3IgUkEgc291cmNlcyBpcyBwcmV0dHkgZWFzeS4gSWYg dGhlIHJvdXRlciBpdHNlbGYgaXMgY29tcHJvbWlzZWQsIHRoaXMgaXMgbXVjaCBoYXJkZXIgdG8g ZGV0ZWN0LiBIYXZpbmcgdGhlIHJvdXRlciBzaWduIGl0cyBSQSBvciBESENQIG1lc3NhZ2VzIHdv buKAmXQgaGVscCB3aXRoIHRoYXQuIEFuZCBpZiB0aGUgbWFubmVyIG9mIGNvbXByb21pc2UgaXMg c2ltcGx5IHRvIGNoYW5nZSBteSBuZXR3b3Jr4oCZcyBwcmVmZXJyZWQgcmVzb2x2ZXIgKGUuZy4s IGZyb20gbXkgSVNQIHRvIENsb3VkZmxhcmUpLCBubyBhbW91bnQgb2YgRE5TU0VDIG9yIGVuY3J5 cHRpb24gd2lsbCBoZWxwLiBCdXQgaWYgdGhleSBjYW4gZG8gdGhhdCwgdGhlbiBtYXliZSB0aGV5 IGNhbiBqdXN0IGNvbXByb21pc2UgbXkgZGV2aWNlcyBkaXJlY3RseSBhbmQgcmVwbGFjZSBteSBh cHBzIHdpdGggY29tcHJvbWlzZWQgdmVyc2lvbnMgdGhhdCBpZ25vcmUgbXkgY2hvaWNlcy4gSW4g YWxsIGNhc2VzIHdoZXJlIHNlY3VyaXR5IGhhcyBiZWVuIOKAnGZvcmNlZOKAnSBvbiBwZW9wbGUg KGUuZy4sIHNlYXQgYmVsdCBsYXdzLCBnb3Zlcm5tZW50IGZvb2QgcmVndWxhdGlvbnMsIGFpcmxp bmUgc2FmZXR5IHJlZ3VsYXRpb25zKSwgdGhvc2UgZG9pbmcgdGhlIGZvcmNpbmcgaGF2ZSB0byBm aWd1cmUgb3V0IHdoYXQgbGV2ZWwgb2Ygc2VjdXJpdHkgaXMg4oCcZ29vZCBlbm91Z2jigJ0gd2l0 aG91dCBtYWtpbmcgY29zdHMgdG9vIGhpZ2guIEZvciBtZSwgdGhlIHRocmVhdCBvZiBhZHZlcnRp c2VtZW50cyBpbiBteSBob21lIG5ldHdvcmsgYmVpbmcgY29tcHJvbWlzZWQgZG9u4oCZdCByaXNl IHRvIHRoZSBsZXZlbCBvZiBzb21ldGhpbmcgSeKAmW0gd2lsbGluZyB0byBpbmN1ciBjb3N0IHRv IGRlYWwgd2l0aC4gTWF5YmUgdGhhdCB3aWxsIGNoYW5nZSBpbiB0aGUgZnV0dXJlLiBCdXQgdGhl IG9ubHkgdGltZSBteSBob21lIG5ldHdvcmsgRE5TIGhhcyBldmVyIGJlZW4gY29tcHJvbWlzZWQg d2FzIHdoZW4gYSBmYW1pbHkgbWVtYmVyIGRvd25sb2FkZWQgYSBjb21wcm9taXNlZCBicm93c2Vy IHRoYXQgaGlqYWNrZWQgRE5TIGRpcmVjdGx5IG9uIHRoZSBmYW1pbHkgY29tcHV0ZXIuIE5vdGhp bmcgd2XigJlyZSB0YWxraW5nIGFib3V0IHdpbGwgaGVscCB3aXRoIHRoYXQuDQoNClRMO0RSOiBV bmxlc3Mgd2UgY2FuIGhhdmUgYSBzb2x1dGlvbiB0aGF0IGlzIHNpbXBsZSBlbm91Z2ggdG8gcHVz aCBvdXQgdG8gYWxsIHBlb3BsZSB3aXRob3V0IHRoZW0gbmVlZGluZyB0byBrbm93IG9yIGRvIGFu eXRoaW5nIHdoaWxlIGFsbG93aW5nIHRoZWlyIGhvbWUgbmV0d29yayBhbmQgZGV2aWNlcyB0byB3 b3JrIGV4YWN0bHkgYXMgdGhleSBleHBlY3QsIHdlIGhhdmUgdG8gY29uc2lkZXIgd2hldGhlciB0 aGUgcGVyY2VpdmVkIGNvc3RzL2NvbmZ1c2lvbi9hbm5veWFuY2UvdmlvbGF0aW9uLW9mLWV4cGVj dGF0aW9ucyBpcyB3b3J0aCB0aGUgYWRkaXRpb25hbCBzZWN1cml0eS4gSeKAmW0gbm90IG9wcG9z ZWQgdG8gc2VjdXJpdHkuIEnigJltIG9wcG9zZWQgdG8gc2VjdXJpdHkgdGhhdCBnZXRzIGluIG15 IHdheSDigJMgZXNwZWNpYWxseSB3aGVuIGl04oCZcyBwcm90ZWN0aW5nIG1lIGZyb20gc29tZXRo aW5nIHRoYXQgaXNu4oCZdCBwcmV2YWxlbnQuPC9iaHM+DQoNCg0KQnV0IHBsZWFzZSBrZWVwIGlu IG1pbmQgdGhhdCB0aGVyZSBhcmUgYWxzbyBzdHJvbmcgbm9uLXRlY2huaWNhbCBkeW5hbWljcyBh dCBwbGF5IGhlcmUuIFRoZSB3ZWIgaW5kdXN0cnkgaGFzIChyaWdodGZ1bGx5KSBzcGVudCB5ZWFy cyB0byBjb252aW5jZSB1c2VycyB0aGF0ICJlbmNyeXB0ZWQgPSBnb29kLCB1bmVuY3J5cHRlZCA9 IGJhZCIuIEFzIGdsb2JhbCBwdWJsaWMgcmVzb2x2ZXJzIGdvIGVuY3J5cHRlZCBhbmQgYnJvd3Nl cnMgcHJvbW90ZSBlbmNyeXB0ZWQgRE5TIGFzIGFuIGltcG9ydGFudCBzZWN1cml0eSBmZWF0dXJl LCBsb2NhbCBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIHdpbGwgYWxzbyBiZSBmb3JjZWQgdG8gZW5j cnlwdCBjb21tdW5pY2F0aW9ucyB3aXRoIHRoZSBsb2NhbCByZXNvbHZlciwgb3RoZXJ3aXNlIHRo ZWlyIHVzZXJzIGFuZCB0aGVpciBib3NzIHdpbGwgY3J5ICJoZXksIGhvdyBjb21lIG91ciByZXNv bHZlciBpcyBzdGlsbCB1bmVuY3J5cHRlZD8geW91IGFyZSBwdXR0aW5nIHVzIGF0IHJpc2shIi4g SXQgZG9lc24ndCBtYXR0ZXIgdGhhdCB0aGUgdGhyZWF0IG1vZGVsIGlzIGRpZmZlcmVudCAtIHVz ZXJzIGFuZCBtYW5hZ2VtZW50IHdpbGwgc3RpbGwgZGVtYW5kIGVuY3J5cHRpb24gZm9yIHRoZSBz YWtlIG9mIGVuY3J5cHRpb24uDQo= --_000_2D09D61DDFA73D4C884805CC7865E6115373E585GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20m Z3Q7IDxicj4NCk9uIEZyaSwgSmFuIDEwLCAyMDIwIGF0IDI6MzggQU0gVml0dG9yaW8gQmVydG9s YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpdHRvcmlvLmJlcnRvbGFAb3Blbi14Y2hhbmdlLmNvbSI+ dml0dG9yaW8uYmVydG9sYUBvcGVuLXhjaGFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWwgMDkvMDEvMjAyMCAyMzowMSBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJt YWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsg aGEgc2NyaXR0bzoNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiA5LCAyMDIwIGF0IDE6MzMgUE0gU1RB UkssIEJBUkJBUkEgSCAmbHQ7IDxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPg0KYnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTogPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZs dDtiaHMmZ3Q7IFRoZXJlIHdvdWxkIHRvdGFsbHkgYmUgYSBwb2ludCBpbiBpbXBsZW1lbnRpbmcg aXQuIFRoZXJlIGFyZSBtYW55IHVzYWdlIHNjZW5hcmlvcyB3aGVyZSB0aGUgYWRtaW5pc3RyYXRv ciBvciB1c2VyIG9mIHRoZSBkZXZpY2UgdHJ1c3RzIChvciBjYW4gZGV0ZXJtaW5lIHdoZXRoZXIg dGhleSB0cnVzdCkNCiBhIG5ldHdvcmsuIEp1c3QgYmVjYXVzZSBESENQIGlzbuKAmXQgdGhlIHJp Z2h0IHNvbHV0aW9uIGZvciBhbGwgc2NlbmFyaW9zLCBkb2VzbuKAmXQgbWVhbiBpdCBpc27igJl0 IHRoZSByaWdodCBzb2x1dGlvbiBmb3Igc29tZSAob3IgZXZlbiBtYW55KSBzY2VuYXJpb3MuIElm IGEgdXNlciBjYW4gYmUgYXNrZWQgd2hldGhlciBvciBub3QgdGhlIG5ldHdvcmsgaXMgcHVibGlj IG9yIHByaXZhdGUsIG9yIHRoZSBhZG1pbmlzdHJhdG9yIGNhbiBpbnN0YWxsIHNvZnR3YXJlDQog dGhhdCBjYW4gZGV0ZXJtaW5lIGlmIHRoZSBkZXZpY2UgaXMgb24gYSB0cnVzdGVkIG5ldHdvcmss IHRoZW4gdGhlIGRldmljZSBjYW4gdXNlIGEgY29tYmluYXRpb24gb2YgYWRtaW4gcG9saWN5IGFu ZCB1c2VyIGlucHV0IHRvIGRlY2lkZSB3aGV0aGVyIG9yIG5vdCB0byBhc2sgZm9yIC8gdXNlIERI Q1Agb3B0aW9ucy4gSnVzdCBiZWNhdXNlIHRoZSBESENQIG9wdGlvbiBpcyBwcm92aWRlZCwgZG9l c27igJl0IG1lYW4geW91IGhhdmUgdG8gdXNlIGl0Lg0KIElmIGEgZGV2aWNlIGRvZXNu4oCZdCB1 c2UgaXQsIHdl4oCZcmUgbm8gd29yc2Ugb2ZmIHRoYW4gbm93LCB3aXRoIG5vIERIQ1Agb3B0aW9u IHNwZWNpZmllZC4gSWYgdGhlIGRldmljZSBkb2VzIHVzZSBpdCwgdGhlbiB3ZeKAmXZlIGF0IGxl YXN0IHByb3ZpZGVkIGEgc29sdXRpb24gZm9yIHRob3NlIHVzYWdlIHNjZW5hcmlvcyB3aGVyZSB0 aGUgbmV0d29yayBpcyB0cnVzdGVkLiBSaWdodCBub3csIHdl4oCZcmUgaG9sZGluZyDigJxuZXR3 b3JrcyB0cnVzdGVkIGJ5DQogdGhlIHVzZXIvYWRtaW7igJ0gaG9zdGFnZSB1bnRpbCBzb21lIGNv bnZvbHV0ZWQgc29sdXRpb24gY2FuIGJlIGNyZWF0ZWQgdGhhdCBhZGRzIGNvbXBsZXhpdHkgYW5k IGNvbmZ1c2lvbiBmb3IgdGhlIHVzZXIgYW5kIG9ubHkgc2VydmVzIHRvIHNoaWZ0IHdobyB0aGUg dXNlci9hZG1pbiBoYXMgdG8gdHJ1c3QgKGJ1dCBkb2VzbuKAmXQgbmVjZXNzYXJpbHkgbWFrZSB0 aGluZ3MgbW9yZSBzZWN1cmUgb3IgcHJpdmF0ZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3Ug ZXhwbGFpbiB5b3VyIHRocmVhdCBtb2RlbCBoZXJlPyBJZiB0aGUgbmV0d29yayBpcyB0cnVzdGVk LCB0aGVuIHdoYXQgYXJlIHlvdSBnYWluaW5nIGJ5IGVuY3J5cHRpbmcgdGhlIEROUyB0cmFmZmlj PyBBcyBJIG1lbnRpb25lZCwgdGhlcmUgc2VlbSB0byBiZSBhIGZldyBlZGdlIGNhc2VzIHdoZXJl IHRoaXMgbWlnaHQgaGF2ZSBzb21lIHZhbHVlLCBidXQgSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCB3 aGF0DQogaXQgaXMgeW91IGhhdmUgaW4gbWluZC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBjYW4ndCBzcGVhayBmb3IgQmFyYmFyYSwgYnV0IEkgZ2VuZXJhbGx5IGFncmVlIHRoYXQgZW5j cnlwdGluZyB0aGUgRE5TIHRyYW5zcG9ydCBjaGFubmVsIGlzIHZlcnkgaW1wb3J0YW50IGlmIHlv dSB3YW50IHRvIGNvbm5lY3QgdG8gYSBmYXJhd2F5IHB1YmxpYyByZXNvbHZlciBvdmVyIGEgbmV0 d29yayB0aGF0IHlvdSBkaXN0cnVzdCwgbXVjaCBsZXNzIHNvIGlmIHlvdSB3YW50IHRvIGNvbm5l Y3QgdG8gYQ0KIGxvY2FsIHJlc29sdmVyIG92ZXIgYSB0cnVzdGVkIG5ldHdvcmsgKHRob3VnaCBh biBhdHRhY2tlciBjb3VsZCBzdGlsbCBtYW5hZ2UgdG8gcGVuZXRyYXRlIHRoZSBsb2NhbCBuZXR3 b3JrLCBzbyB0aGVyZSBpcyBzdGlsbCB2YWx1ZSBpbiBpdCkuDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB0aGUgYXR0YWNrZXIgcGVuZXRyYXRlcyB0aGUgbG9jYWwgbmV0d29yaywgdGhleSB3aWxs IGFkdmVydGlzZSB0aGVpciBvd24gcmVzb2x2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZsdDtiaHMmZ3Q7IEFueSBhdHRhY2tlciB0aGF0IGRvZXMgdGhhdCBpbiBt eSBob21lIG5ldHdvcmsgd2lsbCBiZSBhYmxlIHRvIGNvbXByb21pc2UgYWxsIHNvcnRzIG9mIHRo aW5ncywgYW5kIGNhbiBtZXNzIHVwIGFkZHJlc3MgYXNzaWdubWVudCwgbmV4dCBob3Agcm91dGVy LCBldGMuIElmIGl0IGRvZXMgdGhpcyBieSBhZHZlcnRpc2luZyBpbiBhZGRpdGlvbiB0byBteSBy b3V0ZXIsIGl0IHdpbGwgYWxzbyBjYXVzZSBhDQogcmFjZSBjb25kaXRpb24gdGhhdCB3aWxsIG1h a2UgdGhlIG5ldHdvcmsgYmVoYXZlIGluY29uc2lzdGVudGx5IChteSB0ZXN0aW5nIHN1Z2dlc3Rz IHRoYXQgd2hhdGV2ZXIgZGV2aWNlIGFkdmVydGlzZXMgZmlyc3QsIHdpbnMpLiBPZiBjb3Vyc2Us IGlmIHRoZXkgZG8gdGhpcyBieSBjb21wcm9taXNpbmcgbXkgcm91dGVyLCB0aGVuIEnigJl2ZSBn b3QgZXZlbiBiaWdnZXIgcHJvYmxlbXMuIFJlYWxseSB3aGF0IEkgbmVlZCBpcyBhIG1lYW5zIGZv ciBkZXRlY3RpbmcNCiBzdWNoIGNvbXByb21pc2VzIChzbyBJIGNhbiByZW1vdmUgdGhlbSksIHJh dGhlciB0aGFuIGEgbWVhbnMgdG8gdHJ5IHRvIHBsdWcgdXAgZXZlcnkgcG9zc2libGUgdGhyZWF0 IHRoYXQgbWFsd2FyZSBpbnNpZGUgdGhlIG5ldHdvcmsgcHJlc2VudHMuIEFuZCBkZXRlY3Rpbmcg bXVsdGlwbGUgREhDUCBvciBSQSBzb3VyY2VzIGlzIHByZXR0eSBlYXN5LiBJZiB0aGUgcm91dGVy IGl0c2VsZiBpcyBjb21wcm9taXNlZCwgdGhpcyBpcyBtdWNoIGhhcmRlcg0KIHRvIGRldGVjdC4g SGF2aW5nIHRoZSByb3V0ZXIgc2lnbiBpdHMgUkEgb3IgREhDUCBtZXNzYWdlcyB3b27igJl0IGhl bHAgd2l0aCB0aGF0LiBBbmQgaWYgdGhlIG1hbm5lciBvZiBjb21wcm9taXNlIGlzIHNpbXBseSB0 byBjaGFuZ2UgbXkgbmV0d29ya+KAmXMgcHJlZmVycmVkIHJlc29sdmVyIChlLmcuLCBmcm9tIG15 IElTUCB0byBDbG91ZGZsYXJlKSwgbm8gYW1vdW50IG9mIEROU1NFQyBvciBlbmNyeXB0aW9uIHdp bGwgaGVscC4gQnV0IGlmIHRoZXkNCiBjYW4gZG8gdGhhdCwgdGhlbiBtYXliZSB0aGV5IGNhbiBq dXN0IGNvbXByb21pc2UgbXkgZGV2aWNlcyBkaXJlY3RseSBhbmQgcmVwbGFjZSBteSBhcHBzIHdp dGggY29tcHJvbWlzZWQgdmVyc2lvbnMgdGhhdCBpZ25vcmUgbXkgY2hvaWNlcy4gSW4gYWxsIGNh c2VzIHdoZXJlIHNlY3VyaXR5IGhhcyBiZWVuIOKAnGZvcmNlZOKAnSBvbiBwZW9wbGUgKGUuZy4s IHNlYXQgYmVsdCBsYXdzLCBnb3Zlcm5tZW50IGZvb2QgcmVndWxhdGlvbnMsIGFpcmxpbmUgc2Fm ZXR5DQogcmVndWxhdGlvbnMpLCB0aG9zZSBkb2luZyB0aGUgZm9yY2luZyBoYXZlIHRvIGZpZ3Vy ZSBvdXQgd2hhdCBsZXZlbCBvZiBzZWN1cml0eSBpcyDigJxnb29kIGVub3VnaOKAnSB3aXRob3V0 IG1ha2luZyBjb3N0cyB0b28gaGlnaC4gRm9yIG1lLCB0aGUgdGhyZWF0IG9mIGFkdmVydGlzZW1l bnRzIGluIG15IGhvbWUgbmV0d29yayBiZWluZyBjb21wcm9taXNlZCBkb27igJl0IHJpc2UgdG8g dGhlIGxldmVsIG9mIHNvbWV0aGluZyBJ4oCZbSB3aWxsaW5nIHRvIGluY3VyDQogY29zdCB0byBk ZWFsIHdpdGguIE1heWJlIHRoYXQgd2lsbCBjaGFuZ2UgaW4gdGhlIGZ1dHVyZS4gQnV0IHRoZSBv bmx5IHRpbWUgbXkgaG9tZSBuZXR3b3JrIEROUyBoYXMgZXZlciBiZWVuIGNvbXByb21pc2VkIHdh cyB3aGVuIGEgZmFtaWx5IG1lbWJlciBkb3dubG9hZGVkIGEgY29tcHJvbWlzZWQgYnJvd3NlciB0 aGF0IGhpamFja2VkIEROUyBkaXJlY3RseSBvbiB0aGUgZmFtaWx5IGNvbXB1dGVyLiBOb3RoaW5n IHdl4oCZcmUgdGFsa2luZyBhYm91dA0KIHdpbGwgaGVscCB3aXRoIHRoYXQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRMO0RSOiBVbmxlc3Mgd2UgY2FuIGhhdmUgYSBzb2x1dGlvbiB0aGF0IGlz IHNpbXBsZSBlbm91Z2ggdG8gcHVzaCBvdXQgdG8gYWxsIHBlb3BsZSB3aXRob3V0IHRoZW0gbmVl ZGluZyB0byBrbm93IG9yIGRvIGFueXRoaW5nIHdoaWxlIGFsbG93aW5nIHRoZWlyIGhvbWUgbmV0 d29yayBhbmQgZGV2aWNlcyB0byB3b3JrIGV4YWN0bHkgYXMgdGhleSBleHBlY3QsIHdlIGhhdmUg dG8gY29uc2lkZXIgd2hldGhlciB0aGUNCiBwZXJjZWl2ZWQgY29zdHMvY29uZnVzaW9uL2Fubm95 YW5jZS92aW9sYXRpb24tb2YtZXhwZWN0YXRpb25zIGlzIHdvcnRoIHRoZSBhZGRpdGlvbmFsIHNl Y3VyaXR5LiBJ4oCZbSBub3Qgb3Bwb3NlZCB0byBzZWN1cml0eS4gSeKAmW0gb3Bwb3NlZCB0byBz ZWN1cml0eSB0aGF0IGdldHMgaW4gbXkgd2F5IOKAkyBlc3BlY2lhbGx5IHdoZW4gaXTigJlzIHBy b3RlY3RpbmcgbWUgZnJvbSBzb21ldGhpbmcgdGhhdCBpc27igJl0IHByZXZhbGVudC4mbHQ7L2Jo cyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJ1dCBwbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgdGhlcmUgYXJlIGFsc28gc3Ry b25nIG5vbi10ZWNobmljYWwgZHluYW1pY3MgYXQgcGxheSBoZXJlLiBUaGUgd2ViIGluZHVzdHJ5 IGhhcyAocmlnaHRmdWxseSkgc3BlbnQgeWVhcnMgdG8gY29udmluY2UgdXNlcnMgdGhhdCAmcXVv dDtlbmNyeXB0ZWQgPSBnb29kLCB1bmVuY3J5cHRlZCA9IGJhZCZxdW90Oy4gQXMgZ2xvYmFsIHB1 YmxpYyByZXNvbHZlcnMgZ28gZW5jcnlwdGVkDQogYW5kIGJyb3dzZXJzIHByb21vdGUgZW5jcnlw dGVkIEROUyBhcyBhbiBpbXBvcnRhbnQgc2VjdXJpdHkgZmVhdHVyZSwgbG9jYWwgbmV0d29yayBh ZG1pbmlzdHJhdG9ycyB3aWxsIGFsc28gYmUgZm9yY2VkIHRvIGVuY3J5cHQgY29tbXVuaWNhdGlv bnMgd2l0aCB0aGUgbG9jYWwgcmVzb2x2ZXIsIG90aGVyd2lzZSB0aGVpciB1c2VycyBhbmQgdGhl aXIgYm9zcyB3aWxsIGNyeSAmcXVvdDtoZXksIGhvdyBjb21lIG91ciByZXNvbHZlciBpcyBzdGls bCB1bmVuY3J5cHRlZD8NCiB5b3UgYXJlIHB1dHRpbmcgdXMgYXQgcmlzayEmcXVvdDsuIEl0IGRv ZXNuJ3QgbWF0dGVyIHRoYXQgdGhlIHRocmVhdCBtb2RlbCBpcyBkaWZmZXJlbnQgLSB1c2VycyBh bmQgbWFuYWdlbWVudCB3aWxsIHN0aWxsIGRlbWFuZCBlbmNyeXB0aW9uIGZvciB0aGUgc2FrZSBv ZiBlbmNyeXB0aW9uLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6115373E585GAALPA1MSGUSRBF_-- From nobody Fri Jan 10 10:01:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966A512087E for ; Fri, 10 Jan 2020 10:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 EeTy-T1QLCQL for ; Fri, 10 Jan 2020 10:01:31 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 F1A81120B55 for ; Fri, 10 Jan 2020 10:01:30 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id kx11so1268029pjb.4 for ; Fri, 10 Jan 2020 10:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KEauhcbR44rLagaY6sxfaNLTGTRPesiJ34XL2RdaZyI=; b=MxpCoBGmGnUwxxHVYirx03zmTv/JJGCkHZXA19SsNEb3NJiUok2d5fI+4w4lXo9Bgj UvdOqgfroCQ6WvW5/vua0w+1pY/xqChlNd9NaYiZkdgmv/okEA9J3gbdezehunaa2VWQ sIwokhfyKlps3HtqdV/N5yLdegICT0kI6V/m4d9/dE96eeFGJsLEtfcxYBksf5yjxfWf U07U0OtGas5bqWZ/Dx26bmDuhVeZrq7tU6njB0bIax9095NlPHlZmdL5PgpwXxGSbGzW dVFY6Oiq2DODJwKNINqLV4k0+K3SbWEShuoh9b7A2srnCIUuuMvOnoAUcr44ay9ZyHMa PCsg== 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=KEauhcbR44rLagaY6sxfaNLTGTRPesiJ34XL2RdaZyI=; b=rdYi+UvN0SviKOh7azgWvRnJDLS1f7o8YcMU8dbx0C19CeBi+WBv1/cq5hHPpRDbO/ Qij+m1ulGeM9mav7AE1Dzwa6bcmMOzwgFnBOaifu0mQSeu/ABKZ4lgMgYI2A+zIzLTe9 ExDDWTCQL4RZVl5KjRKriEiRhncUaau+BBraBialvXKpJSyaEHgLkRvcGQZxO95ZqwSH pVRe+3kD6PmZBG8cvZegvkQJ8kNbc8nU/SpxkaZbGK0Xnjv4zlzVK0hXwDRDQofeX7Ob c00//OXT/EUR84Seln8Ckb57GLIM0kBRI0OSpAs4aj5iyVrypZC/3aUKjCEib4+ngoJx DgqA== X-Gm-Message-State: APjAAAUAlQ20TLcMe/b9OYuYcCK4ryGQ9qouWB2zrKLQzKFrYecExewp 9Eq/h0wuY2IDhMdAX0TnhWZOpB8/eT0= X-Google-Smtp-Source: APXvYqzjoC/Mr2fQvAOD5hmK1cwbOR4vSBdJO1Bc4i5i/pnoXdxSkl7yatkBLxQnT5EP4AWV1d9ycA== X-Received: by 2002:a17:902:7c95:: with SMTP id y21mr5761063pll.150.1578679290475; Fri, 10 Jan 2020 10:01:30 -0800 (PST) Received: from encantada.scv.apple.com ([17.192.170.45]) by smtp.gmail.com with ESMTPSA id p28sm3571597pgb.93.2020.01.10.10.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 10:01:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) From: Ted Lemon In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115373E585@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 10 Jan 2020 10:01:28 -0800 Cc: Eric Rescorla , Vittorio Bertola , ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <07E1D5B1-B864-45DE-A9A3-2C1296A43FFE@fugue.com> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <1952958600.26040.1578652730380@appsuite-gw1.open-xchange.com> <2D09D61DDFA73D4C884805CC7865E6115373E585@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 18:01:34 -0000 On Jan 10, 2020, at 9:52 AM, STARK, BARBARA H wrote: > Really what I need is a means for detecting such compromises (so I can = remove them),=20 So e.g. if the DHCP message or RA contains information that=E2=80=99s = been provided by the attacker, and you have a pre-configured trust = relationship with your local resolver, then the DHCP or RA containing a = different configuration could be noticed and flagged, and you=E2=80=99d = realize you=E2=80=99d been compromised. That=E2=80=99s a little different than what I had in mind, but if = there=E2=80=99s a way to know what network you are connected to, then = that might be useful. Of course, if you have all that information = configured anyway, there=E2=80=99s no need to use anything the DHCP = service gives you. IOW, you could have a table of (network-id, resolver-id, = resolver-ip-address) configured on your host, and then you=E2=80=99d = just verify that you=E2=80=99re connected to your local network and then = talk to the configured resolver for that network. Or you could have a = similar table of (network-id, resolver-id) and get the IP address from = DHCP or RA. The latter is probably easier to manage, but then if your network is = attacked, you might get the wrong IP address from DHCP or RA, and then = you=E2=80=99d detect that the relationship (network-id, resolver-id) = doesn=E2=80=99t hold, because the resolver you got would be the wrong = resolver. At that point you could notify the user. This is only possible if you have a way to validate resolver-id /and/ = network-id. > TL;DR: Unless we can have a solution that is simple enough to push out = to all people without them needing to know or do anything while allowing = their home network and devices to work exactly as they expect, I think we have that. > we have to consider whether the perceived = costs/confusion/annoyance/violation-of-expectations is worth the = additional security. I=E2=80=99m not opposed to security. I=E2=80=99m = opposed to security that gets in my way =E2=80=93 especially when it=E2=80= =99s protecting me from something that isn=E2=80=99t prevalent. What I just described is definitely harder to set up than just having = e.g. Mozilla point at 1.1.1.1. As you say, it might be worthwhile, or = might not. But that=E2=80=99s the calculus. It=E2=80=99s not going = to be the other way around, because that=E2=80=99s less secure and more = complicated. From nobody Fri Jan 10 10:01:56 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3A120A52 for ; Fri, 10 Jan 2020 10:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 v-QVivjeD7s2 for ; Fri, 10 Jan 2020 10:01:53 -0800 (PST) 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 0B98512087E for ; Fri, 10 Jan 2020 10:01:53 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47vW5W3FRyzFMZ; Fri, 10 Jan 2020 19:01:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1578679311; bh=/sYQbJnR2jw+T3yxjPQgaPN59Kgsz/UbL1jNugDdjWs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YxLVD34N9x1OOkhuaaIho6IhsBfrAAS8jxrE2vLlGSH1KdOZIP0o2QKQ33sk5pM60 rEIElEWbE8JZ3Mc54v+ktep/q3mQ9aLJDa11G2GOUfBnBbgwcbXl1WA0AjL0dHIhD1 uu2n9gIsgDghkc7fYAYjpmLhxMy6I4mT1cSVSrhY= 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 6SEKLvikJnD3; Fri, 10 Jan 2020 19:01:50 +0100 (CET) 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, 10 Jan 2020 19:01:50 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7DBAF6007AD8; Fri, 10 Jan 2020 13:01:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7C6D62531AC; Fri, 10 Jan 2020 13:01:49 -0500 (EST) Date: Fri, 10 Jan 2020 13:01:49 -0500 (EST) From: Paul Wouters To: Jim Reid cc: Stephane Bortzmeyer , ADD Mailing list In-Reply-To: Message-ID: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <20200110162657.GA6778@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] bikeshedding on the charter discussion X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 18:01:55 -0000 On Fri, 10 Jan 2020, Jim Reid wrote: >> I don't think that resolver discovery *needs* to be addressed. > > Even the question of "how to I find an encrypted DNS resolver for the current network?"? Yes. In your own home network, you can configure encrypted DNS to your own server. In enterprise networks, whatever DHCP DNS can be retrofitted to do encrypted DNS. But the gains are minimal, you might as well work on getting mesh encryption going for ALL traffic in your enterprise. Or uses (non-standard) enterprise provissioning methods that can be extended. In ISP networks, there is very low value in encrypted DNS. If you can't trust your ISP, you basically cannot trust their encrypted DNS either. If you can trust your ISP, their network is properly segmented and secure that basically others cannot snoop DNS traffic. If you don't trust your ISPs ISP, you cannot trust your ISP (eg cable/DSL resellers, where your ISP isn't the one running DHCP/RA). And ISPs publishing their "encrypted DNS policues" that are unverifiable isn't going to help. For roaming devices on wifi, you can never trust what you are told and you are dependend on preconfiguration of known trusted encrypted DNS resolvers anyway. Every network must be deemed hostile, unless you manually override it with your trust. Paul From nobody Fri Jan 10 10:29:03 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B33E120B4C for ; Fri, 10 Jan 2020 10:29:02 -0800 (PST) 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=unavailable 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 pWpActFSEq_e for ; Fri, 10 Jan 2020 10:28:55 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 11296120A8F for ; Fri, 10 Jan 2020 10:28:55 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id a12so1099832uan.0 for ; Fri, 10 Jan 2020 10:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G/Rd2pMgjxfW7IfFqcrukZOU2x+oHuUH+OSZpbEOOGU=; b=qR/JoIrGHrEi+vl++sYqdvz5tibxG3Qy0Y34P07O3iO7MQWEZSYEyA1KyMpG+2XV9z 32+6ZRjF2/CZFAcWG0hOR0nw9ZgtPpMi41s+pTIlx58B37CX1RlPkv9GGN/S6FSSYNK0 iRUwX2BBBvAUbScma7BYOtE513QR6JQ/4bQ/tPSwxb9bbHhyai9fSh4HcxSZuRaFIsQ+ mHzMttRO3dfmTKg3Wg8foBuWODWU8HlqHBD0whWEFGW3YjTG9PCnsk5pH1Y2L1qvrIfg CliWM5d8zszVAIFTtnvVMDq69T1s01lokMEJ9hb1gnQcb2ZPYrhOPZZ85RS7F3XOLoR7 p4Rg== 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=G/Rd2pMgjxfW7IfFqcrukZOU2x+oHuUH+OSZpbEOOGU=; b=PD3ZaUEMHwaHF0QPv5KeAnD9cbFMC64IaIIwB3FKDXlVBZewX87ULRE94ClxYf2fl1 b/sB3xGYVULTEC1PczusgaC59w4/gjttMTjszHZVQk+2Sb7coV0BaqE5ACsHG9Xty81F yIh/mKk4f5/02ZTJhIUSE5vhODhR4Fo+UX4z7pfltI2RSiKNRVay0LQRjGrwUcq7ddq2 mfkmX0qcjLRkurH/NdLUl3bkmxi64P3lLVOzzSRsz8RFcml4S/Z1ohoKwpdYBFVix8F+ VWf9YBtX+RUXXis3Y8RXRKh+d3xy3KBI8/emRtFQqSYqpu3u+MocVQrlwLrYMT0cS1dy 7HtA== X-Gm-Message-State: APjAAAUsJPDZUn6iZ6e871z5AHD51DB1kOtb41XKYYo3jbWr9MR0QEmX 00OWXgbl/a5oAFCe0Rtknl/aOmx17KOXhjYsZOs= X-Google-Smtp-Source: APXvYqxg01KftfHWlaEMkc96vA/Hk2bTHI6jlw7iKZgBxMIfV+VRf4T61J+Rd1t4IyL+TgGqZeqAK0SRvmRNDiSNAOY= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr2818334uaq.114.1578680934175; Fri, 10 Jan 2020 10:28:54 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> <20200110163040.GB6778@nic.fr> In-Reply-To: <20200110163040.GB6778@nic.fr> From: Brian Dickson Date: Fri, 10 Jan 2020 10:28:43 -0800 Message-ID: To: Stephane Bortzmeyer Cc: "STARK, BARBARA H" , Mirja Kuehlewind , Eric Rescorla , ADD Mailing list , Ted Lemon , Vittorio Bertola Content-Type: multipart/alternative; boundary="0000000000004b98fc059bcd4c6f" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 10 Jan 2020 18:29:02 -0000 --0000000000004b98fc059bcd4c6f Content-Type: text/plain; charset="UTF-8" On Fri, Jan 10, 2020 at 8:30 AM Stephane Bortzmeyer wrote: > On Wed, Jan 08, 2020 at 09:34:16PM +0000, > STARK, BARBARA H wrote > a message of 29 lines which said: > > > Why, indeed, are we encouraging a protocol that can be used by > > applications to replace the resolver I and enterprise network > > operators trust with one that we don't? > > To allow people who don't trust the access network to use a distinct > resolver. > > > However, I do think it would be useful to see if we can come up with > > a reasonable way to communicate resolver policy. Even if it's just a > > url where you can indicate your privacy preferences when using that > > resolver. > > Communicate in which direction? User to resolver ("I want this") or > the opposite way ("I provide that")? > I think "negotiate" might be a better term than communicate. I think there is more than one potential end state to such negotiations, if/when you don't trust the resolver offered by the network. I think one challenge is to be able to distinguish implicit (or preferably explicit) rules for network access tied to resolver policy. I think there are definitely places where that tying is completely legitimate, i.e. privately operated networks that have guest access, such as enterprise networks. The two outcomes I'm thinking of for that distrust situation is, "okay, use your pre-configured trusted resolver, I'm cool with that", and "Sorry, you may not join this network." I recognize that these negotiated states may still be reliant on the negotiating parties to behave according to the negotiated state, i.e. that the client doesn't lie about what it says it will do. The starting point in any discussion on whether that negotiation is feasible, is whether these two states are acceptable to participants of the proposed WG. I'll start by asking those expressing strong opinions regarding trust, such as you, Stephane. Do you think this is reasonable (not joining as an outcome, if the client indicates they don't agree)? (This also pre-supposes some pre-established policy by the client, and some vagueness of what is meant by "client", e.g. O/S, user, application, or a combination of those.) Brian --0000000000004b98fc059bcd4c6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 10, 2020 at 8:30 AM Steph= ane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On= Wed, Jan 08, 2020 at 09:34:16PM +0000,
=C2=A0STARK, BARBARA H <bs7652@att.com> wrote
=C2=A0a message of 29 lines which said:

> Why, indeed, are we encouraging a protocol that can be used by
> applications to replace the resolver I and enterprise network
> operators trust with one that we don't?

To allow people who don't trust the access network to use a distinct resolver.

> However, I do think it would be useful to see if we can come up with > a reasonable way to communicate resolver policy. Even if it's just= a
> url where you can indicate your privacy preferences when using that > resolver.

Communicate in which direction? User to resolver ("I want this") = or
the opposite way ("I provide that")?

I think "negotiate" might be a better term than communica= te.

I think there is more than one potential end s= tate to such negotiations, if/when you don't trust the resolver offered= by the network.

I think one challenge is to be ab= le to distinguish implicit (or preferably explicit) rules for network acces= s tied to resolver policy.

I think there are defin= itely places where that tying is completely legitimate, i.e. privately oper= ated networks that have guest access, such as enterprise networks.

The two outcomes I'm thinking of for that distrust sit= uation is, "okay, use your pre-configured trusted resolver, I'm co= ol with that", and "Sorry, you may not join this network."

I recognize that these negotiated states may st= ill be reliant on the negotiating parties to behave according to the negoti= ated state, i.e. that the client doesn't lie about what it says it will= do.

The starting point in any discussion on wheth= er that negotiation is feasible, is whether these two states are acceptable= to participants of the proposed WG.

I'll star= t by asking those expressing strong opinions regarding trust, such as you, = Stephane. Do you think this is reasonable (not joining as an outcome, if th= e client indicates they don't agree)?

(This al= so pre-supposes some pre-established policy by the client, and some vaguene= ss of what is meant by "client", e.g. O/S, user, application, or = a combination of those.)

Brian
--0000000000004b98fc059bcd4c6f-- From nobody Mon Jan 13 01:20:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1931200CE for ; Mon, 13 Jan 2020 01:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZ_Kn1lY-chj for ; Mon, 13 Jan 2020 01:20:06 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110048.outbound.protection.outlook.com [40.107.11.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA711200B3 for ; Mon, 13 Jan 2020 01:20:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ApcLw+5Qa+0ZjFpX/+alN+cYhKz9SdKWVz9GGIBNOvoiuIQWWS8ouGC9BzkyY1G9i7nldvNaX8a09Uv43xyLOtEGMEXQmjLpGhpQ8F7sQQeg88m6Lowwl3AiHY5fjdC6Ok+lGgS+YkOxdlv66+BRtipPda5zcvq4KFwRR2H9iXXpX4A+WUT+fsdi0lcLE/jshE4Yo0BpGmdmknekLoNsQln4vMCOaLJdiUgUUriGZBsc+gnFrW9xKZPGUSGGqRol40OYR1y/b/zaVc4qoGjqu6HuCZMV4B+2bNsmbZ8okls1fnCofPprbqwNenHm2kPS265gjpYQaeAmfE82FJnWbw== 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=drJuTPLRp3sgKQKvRRRlvDaeHQAw/w4L352Qt/19gm8=; b=oCnyaOw/zmz9Dd9+WmylAW2B1Z/ONr1kJxb0uo/ieBGbJ09rbLoACprd8rbMx9mukYcElPyliQANVrHCgra6W+RLxnLq0DVxXLL/6du8QaLQrxSH0LIqhsBsSc5BYcr4O0wHdsl0pny02yjMkmz+lghMVrIOFYXRBalfmd2zSf+pZQx1Bc+4u9mTw3CGvlctvEB7BW3uDabb3NP743PQcndkwr+KKsQ78TrqBUJNeeMjfo40N0NHhajWl1xUQW4oyyhI88ynqx4mJFbF336jGisFpWkdECivFP9TbeZ1hbYSQPw2zYsJ9KCfqWjHvJnBSp6BDyFvQw0mBL4+/5g0VA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=drJuTPLRp3sgKQKvRRRlvDaeHQAw/w4L352Qt/19gm8=; b=NcDV54X/5GfXa4gLgoDmustp7Smis0tkez6J8oB7ycMywoMlzd43OiTHoanxTqCQHiFmmQvoEyPAPuqT9v0pHfZ3DGNcPIi1U43246vz2Tf6Ygq+WrdzaULlBiGZDs0CUwS0xCFTx3YRU1SOjbrX4ILnvllyyLPTUBe+cmgpE/w= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0830.GBRP265.PROD.OUTLOOK.COM (10.166.99.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Mon, 13 Jan 2020 09:20:02 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.015; Mon, 13 Jan 2020 09:20:02 +0000 From: Andrew Campling To: Stephane Bortzmeyer CC: ADD Mailing list , Ted Lemon , "STARK, BARBARA H" , Rob Sayre Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxziFLlI6yeKg7kavCe4wN7Y8zafi6hyggAAFuYCAACJHgIABCcWAgAABUICABDmioA== Date: Mon, 13 Jan 2020 09:20:02 +0000 Message-ID: References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20200110164401.GE6778@nic.fr> <20200110164843.GA8679@nic.fr> In-Reply-To: <20200110164843.GA8679@nic.fr> 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=andrew.campling@419.consulting; x-originating-ip: [86.173.241.3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe1ee4e3-f351-48b9-2675-08d79809c524 x-ms-traffictypediagnostic: LO2P265MB0830: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(346002)(396003)(376002)(366004)(136003)(189003)(199004)(8676002)(44832011)(66574012)(55016002)(81156014)(71200400001)(9686003)(86362001)(4326008)(2906002)(81166006)(53546011)(54906003)(508600001)(76116006)(66446008)(7696005)(6916009)(6506007)(33656002)(66476007)(66556008)(66946007)(5660300002)(64756008)(8936002)(26005)(52536014)(316002)(186003)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0830; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: amiltz4guKRBgJU8Otw0qP8kyDbBtTIYY/iDmfo6xK+F+T6OlO9c04g51eDjIkeJLIgDSHNT7VGsz5N2gYyseQHxFdWqXVqeMN5qNbDUS9/911WXrFJAmXDctHIyOh7wWm1w044pO6QfzF+aWCPP8nSDylBV5bEaNWS3VtvYGPENJLGt3GU6BctVehlpwgogIMcCEKhyYThg50oqTTbxGKEqfZtO7dYvfG+uT43LKrGaBinSg0rXPaOYk4cSzDioTl8h8aHB9/S5adH59wpyHB/vgfqC/hdcJ6AE9cWSMZhrqoxT16D1sglRBpNnNzI7UJpNm6lfoVF2VyghuIV/MRu+B/BECfPLhyXT1/IyW2RJvBlpF6fAo4+gx2Lc2Af/dBlKaukRYANx3bwpvdleRkWWMjJW+GNUi+dVi1Qk93coe8HyFQUllbupRgpdBla0ppfLbqL1ISUyKzDcloAs7psL6GA+YAsVGE6Xf0DsNVobWQJSqWJdmk71W8QMQWOU x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: fe1ee4e3-f351-48b9-2675-08d79809c524 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2020 09:20:02.5552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NpnWqWvHKPUEK9aRXTK0EBbjxbnCBzZwRQSZltIQIzIYwNUeL6MJDicoM+fw0jnc4+uQGxAEy20lzadebKmpLkMEhS2rwhvy27fALYSIFdc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0830 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 09:20:08 -0000 On Fri, Jan 10, 2020 at 17:49, Stephane Bortzmeyer wro= te: > On Fri, Jan 10, 2020 at 05:44:01PM +0100, Stephane Bortzmeyer wrote a message of 24 lines which said: >> It seems to me that the RFC1958 opinion is very fundamental in all the=20 >> Internet protocols (compared with, say, traditional telco >> protocols) and changing it is not in-scope for this list. I don't=20 >> think that IETF would agree to revise this end-to-end principle. > And I forgot to mention RFC 3552, which is probably even more relevant th= an RFC 1958. It clearly explains that our threat model is "the network may = be hostile and we cannot rely on it". So now we have references to two RFCs, one from 1996 and one from 2003, bot= h of which were written when the internet and web were very different to to= day. As posted elsewhere, both of these RFCs pre-date the rise of "surveil= lance capitalism"; the many privacy breaches by apps (and "smart" devices);= and the accelerating consolidation leading to a few corporations dominatin= g large parts of the Internet with the consequent loss of resilience (I not= e that the Internet Society is currently exploring the impact of consolidat= ion in chapter meetings). Therefore, the view that it is better to rely on= the confidentiality or integrity of endpoints rather than carriers/network= s is at best questionable and is certainly dated. Andrew=20 From nobody Mon Jan 13 03:18:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8F1200DF for ; Mon, 13 Jan 2020 03:18:29 -0800 (PST) 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 Y6NAdptcj8i5 for ; Mon, 13 Jan 2020 03:18:27 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 CC8851200DB for ; Mon, 13 Jan 2020 03:18:26 -0800 (PST) Received: from 200116b82c8ff80001209f0113a83d8c.dip.versatel-1u1.de ([2001:16b8:2c8f:f800:120:9f01:13a8:3d8c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iqxji-0001K1-KV; Mon, 13 Jan 2020 12:18:22 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 13 Jan 2020 12:18:21 +0100 Cc: Jim Reid , ADD Mailing list , Stephane Bortzmeyer Content-Transfer-Encoding: quoted-printable Message-Id: <7BFE5044-E83C-42E0-B485-9E8F4AF0F7BB@kuehlewind.net> References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <20200110162657.GA6778@nic.fr> To: Paul Wouters X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578914306;8e52cdca; X-HE-SMSGID: 1iqxji-0001K1-KV Archived-At: Subject: Re: [Add] bikeshedding on the charter discussion X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 11:18:29 -0000 I think the underlying idea of Adaptive DNS and the proposed charter is = that you maybe want to use more than one resolver depending on the = service you are requesting.=20 > On 10. Jan 2020, at 19:01, Paul Wouters wrote: >=20 > On Fri, 10 Jan 2020, Jim Reid wrote: >=20 >>> I don't think that resolver discovery *needs* to be addressed. >>=20 >> Even the question of "how to I find an encrypted DNS resolver for the = current network?"? >=20 > Yes. >=20 > In your own home network, you can configure encrypted DNS to your own > server. >=20 > In enterprise networks, whatever DHCP DNS can be retrofitted to do > encrypted DNS. But the gains are minimal, you might as well work on > getting mesh encryption going for ALL traffic in your enterprise. Or = uses > (non-standard) enterprise provissioning methods that can be extended. >=20 > In ISP networks, there is very low value in encrypted DNS. If you = can't > trust your ISP, you basically cannot trust their encrypted DNS either. > If you can trust your ISP, their network is properly segmented and > secure that basically others cannot snoop DNS traffic. If you don't > trust your ISPs ISP, you cannot trust your ISP (eg cable/DSL = resellers, > where your ISP isn't the one running DHCP/RA). And ISPs publishing > their "encrypted DNS policues" that are unverifiable isn't going to > help. >=20 > For roaming devices on wifi, you can never trust what you are told and > you are dependend on preconfiguration of known trusted encrypted DNS > resolvers anyway. >=20 > Every network must be deemed hostile, unless you manually override it > with your trust. >=20 > Paul >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add >=20 From nobody Mon Jan 13 04:51:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C651200F5 for ; Mon, 13 Jan 2020 04:51:23 -0800 (PST) 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 yWDAoIG9YNUy for ; Mon, 13 Jan 2020 04:51:21 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 3C37E1200FE for ; Mon, 13 Jan 2020 04:51:21 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id a13so9878049ljm.10 for ; Mon, 13 Jan 2020 04:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4FmThp2VbCiZIwhO5hEkf2VEP/MrhkqJ3vtjIA7Qmes=; b=cOwlUPfi4CD0iO1TppwrvGmhV+SoaJwz5FMsdNN2+dFvLPr7T4EnH4RJqKhmNGgA+r 5ovj9F4kAS6AEIZhhEqalrsMs5b1hafz/mAMNxIHHwIefVqeLOL79cttAHZf+Sk2LOzk plzrCExWk1nOx/CdNuTO/TT3woqfMI2FPBMZi/zkRJmU8CZos9KRZZ9I1PIvNSqr66J3 Ge5lGYn+ccSrjmBa1/w3VMMTiLe/kBdhBt8i5cBXiZ6EU5tD4Q+dgmqNkh3SUFe8OtU2 NwD7Ow43PcF+l7X5rls5Gf7pRn92wuFarG8FWdX1b/5ULX0GoI5M6CqoDIhVBAfjYo0R uV+g== 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=4FmThp2VbCiZIwhO5hEkf2VEP/MrhkqJ3vtjIA7Qmes=; b=XV5MGCFfgL0r2viPyrI76hhshztQ80IfXTZC5rsvpe+arveKBe0m+mZAbX1DxkgqRS QxhVsfBD+GZNuN5bupkEdlSUpJiCX60zUt1H8j/keF3NrxR0HlLEsiyGdntotHsaFDwz rgNrk8lzmTE2L23afb1xcCgVE4gj6R//aIcvioAs6Sov1lAlTLU/EOmn2msr/J9/7PiD agE3+QwER3zYvPQuBMzn1nq3OSo2b6qeFeGrjlgeADYB21GBZeIbMdgiA7xwOYNfHnwu SnGGlvjDr/I+lfw47GnlO7bG18DRmFTZ9s4GS0/NbR+NIcBpYJwyN0iJK139uSsHRyYS Zn4Q== X-Gm-Message-State: APjAAAUZFeBq36QQxutUI+UsFus9FDB6GmsPcmkXBOmg+yzpxf2gAco0 0gXmjcC8mrVMHKp+zEHLW3ug4JCESfR8kaXXXK81QA== X-Google-Smtp-Source: APXvYqwx3hgC1coU+xkhN8v1+Db5nrt6g2Q9Bs5uPHZkJQ9lZbyuWg7//Pgbj6t+5qbGeughMxBeQM4VFVK7qU+rvIw= X-Received: by 2002:a2e:9510:: with SMTP id f16mr10409591ljh.249.1578919879520; Mon, 13 Jan 2020 04:51:19 -0800 (PST) MIME-Version: 1.0 References: <3d5da3a9-200f-61ea-0c78-3e7930f3003d@cs.tcd.ie> <223B51EE-6FBA-4A01-8254-E9957F00BCD6@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373CD75@GAALPA1MSGUSRBF.ITServices.sbc.com> <20200110164401.GE6778@nic.fr> <20200110164843.GA8679@nic.fr> In-Reply-To: From: Eric Rescorla Date: Mon, 13 Jan 2020 04:50:43 -0800 Message-ID: To: Andrew Campling Cc: Stephane Bortzmeyer , ADD Mailing list , Ted Lemon , "STARK, BARBARA H" , Rob Sayre Content-Type: multipart/alternative; boundary="0000000000008c4237059c04eee6" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 12:51:23 -0000 --0000000000008c4237059c04eee6 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 13, 2020 at 1:20 AM Andrew Campling wrote: > On Fri, Jan 10, 2020 at 17:49, Stephane Bortzmeyer > wrote: > > > On Fri, Jan 10, 2020 at 05:44:01PM +0100, Stephane Bortzmeyer < > bortzmeyer@nic.fr> wrote a message of 24 lines which said: > > >> It seems to me that the RFC1958 opinion is very fundamental in all the > >> Internet protocols (compared with, say, traditional telco > >> protocols) and changing it is not in-scope for this list. I don't > >> think that IETF would agree to revise this end-to-end principle. > > > And I forgot to mention RFC 3552, which is probably even more relevant > than RFC 1958. It clearly explains that our threat model is "the network > may be hostile and we cannot rely on it". > > So now we have references to two RFCs, one from 1996 and one from 2003, > both of which were written when the internet and web were very different to > today. As posted elsewhere, both of these RFCs pre-date the rise of > "surveillance capitalism"; the many privacy breaches by apps (and "smart" > devices); and the accelerating consolidation leading to a few corporations > dominating large parts of the Internet with the consequent loss of > resilience (I note that the Internet Society is currently exploring the > impact of consolidation in chapter meetings). Therefore, the view that it > is better to rely on the confidentiality or integrity of endpoints rather > than carriers/networks is at best questionable and is certainly dated. > I think I disagree with your implied argument.There's not much evidence that the network has done much of anything to ameliorate surveillance capitalism, as opposed to trying to get into the game itself. However, this isn't the place to debate the Internet threat model. If you want to do that, I would suggest you join the IAB's new "model-t' effort. -Ekr > > Andrew > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000008c4237059c04eee6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 13, 2020 at 1:20 AM Andre= w Campling <andrew.campling@419.consulting> wrote:
On Fri, Jan 10, 2020 at 17:49,=C2= =A0 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:

> On Fri, Jan 10, 2020 at 05:44:01PM +0100,=C2=A0 Stephane Bortzmeyer &l= t;bortzmeyer@nic.fr<= /a>> wrote=C2=A0 a message of 24 lines which said:

>> It seems to me that the RFC1958 opinion is very fundamental in all= the
>> Internet protocols (compared with, say, traditional telco
>> protocols) and changing it is not in-scope for this list. I don= 9;t
>> think that IETF would agree to revise this end-to-end principle.
> And I forgot to mention RFC 3552, which is probably even more relevant= than RFC 1958. It clearly explains that our threat model is "the netw= ork may be hostile and we cannot rely on it".

So now we have references to two RFCs, one from 1996 and one from 2003, bot= h of which were written when the internet and web were very different to to= day.=C2=A0 As posted elsewhere, both of these RFCs pre-date the rise of &qu= ot;surveillance capitalism"; the many privacy breaches by apps (and &q= uot;smart" devices); and the accelerating consolidation leading to a f= ew corporations dominating large parts of the Internet with the consequent = loss of resilience (I note that the Internet Society is currently exploring= the impact of consolidation in chapter meetings).=C2=A0 Therefore, the vie= w that it is better to rely on the confidentiality or integrity of endpoint= s rather than carriers/networks is at best questionable and is certainly da= ted.

I think I disagree with your impli= ed argument.There's not much evidence that the network has done much of= anything to ameliorate surveillance capitalism, as opposed to trying to ge= t into the game itself. However, this isn't the place to debate the Int= ernet threat model. If you want to do that, I would suggest you join the IA= B's new "model-t' effort.

-Ekr
<= div>


Andrew

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000008c4237059c04eee6-- From nobody Mon Jan 13 05:41:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BED120104 for ; Mon, 13 Jan 2020 05:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcnRuV0WXT5d for ; Mon, 13 Jan 2020 05:41:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1538612004F for ; Mon, 13 Jan 2020 05:41:03 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6E02C28019A; Mon, 13 Jan 2020 14:40:59 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 654B828053A; Mon, 13 Jan 2020 14:40:59 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 5D0A028019A; Mon, 13 Jan 2020 14:40:59 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 55E19663E080; Mon, 13 Jan 2020 14:40:59 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 5130A433B3; Mon, 13 Jan 2020 14:40:59 +0100 (CET) Date: Mon, 13 Jan 2020 14:40:59 +0100 From: Stephane Bortzmeyer To: Brian Dickson Cc: Stephane Bortzmeyer , "STARK, BARBARA H" , Mirja Kuehlewind , Eric Rescorla , ADD Mailing list , Ted Lemon , Vittorio Bertola Message-ID: <20200113134059.GA5234@nic.fr> References: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> <20200110163040.GB6778@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 10.2 X-Kernel: Linux 4.19.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000018, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 13:41:06 -0000 On Fri, Jan 10, 2020 at 10:28:43AM -0800, Brian Dickson wrote a message of 118 lines which said: > I think "negotiate" might be a better term than communicate. ... > I think one challenge is to be able to distinguish implicit (or preferably > explicit) rules for network access tied to resolver policy. ... > I'll start by asking those expressing strong opinions regarding trust, such > as you, Stephane. Do you think this is reasonable (not joining as an > outcome, if the client indicates they don't agree)? I think your ideas are interesting, and it would be cool if it worked but I'm skeptical. First, some people don't want to negotiate (you typically do not discuss the policies with your Internet Access Provider: it is "take it or leave it"). Second, protocols with negotiation are hard to get right, specially security-wise. There will be risks of downgrade attacks. (A good example is the canary domain, which allows a network to easily disable security on the client.) From nobody Mon Jan 13 05:59:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073AD12010D for ; Mon, 13 Jan 2020 05:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hm2Kn81jI62Z for ; Mon, 13 Jan 2020 05:59:25 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA80D12010C for ; Mon, 13 Jan 2020 05:59:25 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id a203so8521665qkc.3 for ; Mon, 13 Jan 2020 05:59:25 -0800 (PST) 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=CxUMGY3COhodYXwfwAJ8qBGAvAbrCk/fpnbLw+cPtxQ=; b=r0VoCdSCBKxNXOnsG0ZPpf5NmUACuF9X93pQuXTJTz4tl3fkcapNCRDJyDe8pJT5Kt zdUFpJN14EHjBWGobf9MEQPKtC1QGRkfdB0oYErS3uGsB+6z5dz7CMdHekwWFRtexNK9 Ncv6yYNrA2PSCbmIo3pac1cAaBbuPFxF9Pil71K8Bep1rtlOu+pZLbX+jvw89CNmWicV mbQPjY4opylkK770fLLPfqK9IOjebGbvRL2MzStX3+fe2irA9CJZUGchY+ijHlSh1UOA Lup+LA1yR0ZvD+zcXoiNqDXPKcU/XYNKGLH27y5d/cQZFPkUUA/jGWYxjv1TFOg59muc AFBg== 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=CxUMGY3COhodYXwfwAJ8qBGAvAbrCk/fpnbLw+cPtxQ=; b=EXK3p/jMEWQ9RHkcSrBr6bEV8gDcZp16r8SssolTCSH0lnuNwlD6qweCAdMiSZcImC fHtRoyxdDNGCq+1y2QRNuEU/vXE+BFb32O+cInJM8hRtFmKwqVW71xTIyLp2rX3nKL13 MIWhpMlJ77Y5GevpqAR62O5oiISO5HcXBYCTbLYax+/g+IKs0wor7SjEpieLZU9QbQsb KksukRZTbXMyr/jlqs/viYkZzZHi1waZuAYmV8BwcU2+5EKJXu1/PLPMoMZj9XrlzsQe +Ik21t0/oKcTNKsv0pf7F0D3GjeQjqk58TETSRoxl16ClLXU1BP6w64TL3TzS7UnNZIb FfbA== X-Gm-Message-State: APjAAAXGYPZjSZv0AeJ3yZmY1HcNbgVxJ8X3o8Xq4t1u2K7caPjPClNc rVlBmUt5XAb0Eod/lIxM8c+4ZQ== X-Google-Smtp-Source: APXvYqxHWvPy+l0hxWx63qBsZBftEMn4bcmKZ1xdBqtkY5MvlG0H6UK/YsMZa8Z09sq1H5HPH+xsnA== X-Received: by 2002:ae9:e306:: with SMTP id v6mr16130413qkf.162.1578923964822; Mon, 13 Jan 2020 05:59:24 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:3976:b377:75a5:3985? ([2601:18b:300:36ee:3976:b377:75a5:3985]) by smtp.gmail.com with ESMTPSA id 200sm5041588qkn.79.2020.01.13.05.59.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jan 2020 05:59:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 13 Jan 2020 08:59:23 -0500 Message-Id: References: Cc: Stephane Bortzmeyer , ADD Mailing list , "STARK, BARBARA H" , Rob Sayre In-Reply-To: To: Andrew Campling X-Mailer: iPhone Mail (17E202) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 13:59:28 -0000 Of course, in addition, this whole debate is ultimately about an RFC written= in 1987, so perhaps you should just stop using DNS entirely if this is how y= ou evaluate the worth of RFCs? > On Jan 13, 2020, at 04:20, Andrew Campling wrote: >=20 > So now we have references to two RFCs, one from 1996 and one from 2003, bo= th of which were written when the internet and web were very different to to= day. From nobody Mon Jan 13 06:39:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613E712003E for ; Mon, 13 Jan 2020 06:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdFnYmZ7d05k for ; Mon, 13 Jan 2020 06:39:00 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110081.outbound.protection.outlook.com [40.107.11.81]) (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 39D3D1200D6 for ; Mon, 13 Jan 2020 06:39:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K93WA2osWzEBos+6hA0bBh3Mth4sqmW/vtbXF+CTKAQJ2n0ZdeQrDTCT0PphtCckpuPoLwfr4NUmkZbF1opTmXy8cKJmGW1hSS+78hvgn0d43FCoBqxJpRte0bKjKuRrphQ6QLLTfVsrVstSKiEOnqiGAl0WKAQDLUiTmTKsDBKS27uzjdLn/YRjNOgUGk9BLKehw8YpXIkXq6uW0tw3C+sbfbh3HXqB8+6YKpmzoOScGq08j6PcxrMLV5h9gdf++g4iZSoyo26kleO2r3DBSZJ9dUEm6oy9p66TfZx7sG4tnBikjHolsVi88E5e1Rp+tDhUMHSR/V7DGfMnGQoQWw== 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=UERcufHbV3POT6lla6d8W02telP1WpLy3Px3qtqkN44=; b=I/ZtO48s7VROEfVkfpUxHZ84sFeQ5grf9PHK69N6Dl9WR5pb11W26XDosVhKm6PnUStjAsfT6/iMR1i+/jUQGE87GrLvB58tRWKIjIqumEwod9Yql9frqdobgI4a3e+IC0txdnv3Ip2wNO5gjpl+ZFAPmDAG4Wqq20nzeSNqWCDTkVHaKg22qG4s+GFkD/9gGDy/jx+RdOKCq06Ow4yyyUYr1PJuxRSe3OyNTu1un6hdgHDbG1s68mwNp7PIchDAwamT6cz33Cr7Wtw9kLmzUUUdulxDHYKqhm3yME9L6KiVF+MqcM4tUstQsLDUGB2KaOr0Kbt7DTR085ZP1NJs0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UERcufHbV3POT6lla6d8W02telP1WpLy3Px3qtqkN44=; b=UhChLn7lPJA1ELMs8ZTawtqV+RwQga/dc/i78n/Wz8SLLNCO4n0v3amNdz5LlVwwkct80IKz6kvNvNmAtWHQS7KswRc+RpN+JIEZeWorP8L/dsdisVxydItaFuynkvm994S5J/IJrV6NEBCQc6Xx+5WP0VpPBu7bGIxhls57eH0= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0622.GBRP265.PROD.OUTLOOK.COM (10.166.98.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Mon, 13 Jan 2020 14:38:56 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.015; Mon, 13 Jan 2020 14:38:56 +0000 From: Andrew Campling To: Ted Lemon CC: Stephane Bortzmeyer , ADD Mailing list , "STARK, BARBARA H" , Rob Sayre Thread-Topic: [Add] A proposed charter for ABCD Thread-Index: AQHVxziFLlI6yeKg7kavCe4wN7Y8zafi6hyggAAFuYCAACJHgIABCcWAgAABUICABDmioIAATg2AgAAHcMA= Date: Mon, 13 Jan 2020 14:38:56 +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=andrew.campling@419.consulting; x-originating-ip: [86.173.241.3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb55af17-b55a-4092-a06d-08d7983651bf x-ms-traffictypediagnostic: LO2P265MB0622: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(39830400003)(376002)(396003)(199004)(189003)(8676002)(81166006)(81156014)(316002)(4744005)(508600001)(54906003)(5660300002)(4326008)(52536014)(66476007)(76116006)(66946007)(66556008)(55016002)(9686003)(64756008)(66446008)(8936002)(6916009)(86362001)(44832011)(53546011)(2906002)(186003)(71200400001)(26005)(33656002)(7696005)(6506007)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0622; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CRvzOz5IO1k/O8LRtptKKOGrNFeT2xIgmY9UQcjgrhz/JTu3UpJPb1o8dgs6weKNCnC1mUIYdLauUt2rXDAddAATWnoUXJJozDWzl9NP+K36XNfalpEgzGUUZdaOpwg+v7peLiamBMtSO8IbXjAPoyTS4ZgoTq/ZxXozmMY/9ieR+pbWHqJ/8GTjmi2/cMZsSHQMvN1foZFRCFbASUmAYCMhZHisBW0AL46W6aEUIb1bAIqnt/f/V2ZKlIs4TYaFdDDpa7n+dwxAA2kGCLjuDrD2zZ4VLfKnR3ZDSIY6C8LOLd14Jn/0p8Zu+41/dPBjpKXXa3mrGTiUko/K9oztP56oBURMnWvYBUddosi/pRfnfmuxRN54lC04nsUVTNgI4ehrbayvYrNJsNmbT5zDG+q0v/6VQOtjwQ21dG+iMHGYlNDJPqzvvr9gDFHpApAHPeGQXHcKrUkC21FhoOkGn/DvK7OAW2GDc45A2+csJdiGK4ZaGKEtPF1b1Qgzhx2S x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: eb55af17-b55a-4092-a06d-08d7983651bf X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2020 14:38:56.2703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Uo9Nd+8J+X8LyuPdOTRqqSs2zOeY1DVirf7SWyMjQy3ZSCxBfObksFt8berJVLoiDloiOIxPkY/jjTV5CGtLEBciK7+rCbLJANf1Zj3fiY4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0622 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 14:39:03 -0000 > On Jan 13, 2020, at 13:59, Ted Lemon wrote: >=20 > Of course, in addition, this whole debate is ultimately about an RFC writ= ten in 1987, so=20 > perhaps you should just stop using DNS entirely if this is how you evalua= te the worth of RFCs? I note that RFC 1034 includes references to updates from 18 subsequent RFCs= ; by contrast, RFC 1958 lists one and RFC 3552 lists none. I think it reas= onable to suggest that, for example, a BCP covering security considerations= may need updating after 16 or so years - note this is not to suggest that = the content is not valuable, simply that it might not fully reflect the cur= rent situation. However, as one of its authors has suggested, this discuss= ion can be continued under the auspices of the IAB's "model-t' list. Andrew=20 From nobody Mon Jan 13 06:51:17 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82173120104 for ; Mon, 13 Jan 2020 06:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w84Ucgki-naj for ; Mon, 13 Jan 2020 06:51:14 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D490E12003E for ; Mon, 13 Jan 2020 06:51:13 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id r14so8647829qke.13 for ; Mon, 13 Jan 2020 06:51:13 -0800 (PST) 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=Y2SocyrGem7l9QXDXMdaXElKx9Ulnd0ntrqL2E7F+YQ=; b=ogPHBVfuBkF+O2HLR9eydHwJAbeKRgC8dypKbMu4S3hAMaSYNoAOqLTCqHNK+CQl2h WNwDgO3dk5OruGD4TjbMjpcWD0eI/K6eGRBTTnf8qqHlc9mmchcRSIA8NdmlpfrX/bgK QCqjUKwVwDcu2CtZUnmKHy/6aprWi/H4e6cTxWs2dT4sFaoazXpPUor3cJakMtwmz3/f L1p+myLJ9qEGY3FfWdTvI6vLiKclFy/VofQm+tCRNFDxAmjnWN6CA3BRm2SQbcFsuycg w+1dDd8ITNuufb76BaeplVWpdxBWhLWBi1nU9Ids5EVdJpxaPTuGzkbvmBZrzBAIR1Ly HVLw== 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=Y2SocyrGem7l9QXDXMdaXElKx9Ulnd0ntrqL2E7F+YQ=; b=ookZxi3DimrMkVMLyCsBDGz4RR9jvsxKqj1XOmpb+XVHKIKZ6KYJfVYfGErqrVVG7C 4SrudL2wRUhPbE+jRdrck2rNikelrSg5A29ddsERSPe7/sbNXu8tAR4IDphf/AC4iL4z Apn/j2abDCNExADCtqFmyF0bgjA06jVlrL2jK85Lk8HCbnSeF4CkXDhiXWTir6G2PjhE Ijr6jmhetBQp9lQnUullMBRupToWc/DVgJBHcDcFA6K3Gq0T18ahb+B6yca49uVKN/rM wTl1qSSgxkSMTIXxQkk/0d3pgccOpSfzYuYdn2x+UTpc4oa1f37a611Fpnpcwsyh1pho sdaw== X-Gm-Message-State: APjAAAVKrGNO7n8cHkmp8T5oI6Ia3k5m10m3+3KhjwFcNr3QTEjvBECN O0vsvWG8undnwk6A1gYAJRPGtQ== X-Google-Smtp-Source: APXvYqyD0KZlW/Fx77JuQWNnfcSr8Fna08ajJkEzUujOrJJipeYwHsfTEtirDukXxNK2/h7M9C9fyA== X-Received: by 2002:a37:af86:: with SMTP id y128mr16579642qke.107.1578927072943; Mon, 13 Jan 2020 06:51:12 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:3976:b377:75a5:3985? ([2601:18b:300:36ee:3976:b377:75a5:3985]) by smtp.gmail.com with ESMTPSA id j185sm5073232qkc.96.2020.01.13.06.51.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jan 2020 06:51:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 13 Jan 2020 09:51:11 -0500 Message-Id: References: Cc: Stephane Bortzmeyer , ADD Mailing list , "STARK, BARBARA H" , Rob Sayre In-Reply-To: To: Andrew Campling X-Mailer: iPhone Mail (17E202) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 13 Jan 2020 14:51:16 -0000 There have been a lot of updates to the IETF=E2=80=99s policies on privacy i= n later RFCs. They just don=E2=80=99t happen to support your position.=20 > On Jan 13, 2020, at 09:39, Andrew Campling wrote: >=20 > =EF=BB=BF >>=20 >> On Jan 13, 2020, at 13:59, Ted Lemon wrote: >>=20 >> Of course, in addition, this whole debate is ultimately about an RFC writ= ten in 1987, so=20 >> perhaps you should just stop using DNS entirely if this is how you evalua= te the worth of RFCs? >=20 > I note that RFC 1034 includes references to updates from 18 subsequent RFC= s; by contrast, RFC 1958 lists one and RFC 3552 lists none. I think it reas= onable to suggest that, for example, a BCP covering security considerations m= ay need updating after 16 or so years - note this is not to suggest that the= content is not valuable, simply that it might not fully reflect the current= situation. However, as one of its authors has suggested, this discussion c= an be continued under the auspices of the IAB's "model-t' list. >=20 > Andrew=20 >=20 From nobody Tue Jan 14 09:57:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5A1208FA for ; Tue, 14 Jan 2020 09:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IqVfD0swesh for ; Tue, 14 Jan 2020 09:57:31 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 BB896120804 for ; Tue, 14 Jan 2020 09:57:31 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id k14so13505462otn.4 for ; Tue, 14 Jan 2020 09:57:31 -0800 (PST) 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=R2wWAaG3c5jMb8ril5djaNY1fWuYf5U3mO2pWPY4TrM=; b=reAVbR9lOsbPamZGf1tQaDXXOWVegLdSzIBfXHmt0315FOqmJpKnEmdIu07kgKHaZm 5jdgJO2iHjCSNcmaitcR6pYWIoQpIjMzm932Z/HgsYRgxfW5xhWMkHEY9qtfa2WCeJb+ hAeVpJ0Ss1RcVU9ySEGn6l4F218OEBP7Cd5muPCgFLQVENBcbs15GOhbFUCTISN45Y1I oHRIertWIE2QpWi1wCmNxB6v6LwkqPGK61cPIV3l73nFI6t3PpN+FE6HMXxjsDe4ItFz XSLLsx8ypWT1W01cw0ikrN7PizraK6GMSBalMvBqz+t2At5qk2pp5+2iR130FBeWbCNp ctxg== 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=R2wWAaG3c5jMb8ril5djaNY1fWuYf5U3mO2pWPY4TrM=; b=ArXpo7h5Ypmp9Ui+LT4Yo+yBoedUc8SkJR5YYAzltz0BFkAadDXbCIweIhgFROhtJO 2pKVPcWhsbhySVOAGDdKmhfTvjnnC0I+lUJ5Zq9xijuLoCsXJZZD6aAoNKJkNIt4szD0 sIEtkAA0Nrgovt4ZErcj4c2gDKx9+ah59iY5+VnaddU4CEoOXBpof1OW7nyvuptECDJU khvPCGjohpWaQP0MU82Lw8VgdBygozIU6KQW1ZqwNe8u+TWsXe/hYOl4uhz9XideEtgz uIpXKs8WjS4o4Jx4WXTbZbBZVWKo7s89dQEPxrEQ37p++iSPXMnxGacmd1fWv45q8+DH iX7w== X-Gm-Message-State: APjAAAVqg5D5Dl2DBb65TQ7O4gxjUMGrP0pCRkjhds5T1lufcGSf3yCI VK/KiqqJOQDoEcZOIs17gmyIrU35DYi7X5UDxW8/Hg== X-Google-Smtp-Source: APXvYqx2YCPRMQAbiWVTjtHUfS1BBpnu36dohGptvoml+diQLam+5BeC0gfUcI3LcsCfipj/utyJb3OukBk73U5+4eA= X-Received: by 2002:a05:6830:151a:: with SMTP id k26mr18882090otp.74.1579024650817; Tue, 14 Jan 2020 09:57:30 -0800 (PST) MIME-Version: 1.0 References: <895265046.19237.1578488818611@appsuite-gw2.open-xchange.com> <1028960943.19923.1578496828029@appsuite-gw2.open-xchange.com> <03F74927-CA48-42D9-8C8C-21553C4029F9@kuehlewind.net> <4E96E46D-583F-442C-9E6A-93B36B7AAA11@kuehlewind.net> <58F06DFF-502F-4180-8466-CB26A39F68AA@fugue.com> <2D09D61DDFA73D4C884805CC7865E6115373AEC0@GAALPA1MSGUSRBF.ITServices.sbc.com> <5B682191-0638-4711-AE91-40D0626540B3@cable.comcast.com> <20200110163451.GC6778@nic.fr> In-Reply-To: <20200110163451.GC6778@nic.fr> From: Kenji Baheux Date: Wed, 15 Jan 2020 02:08:25 +0900 Message-ID: To: Stephane Bortzmeyer Cc: "Livingood, Jason" , ADD Mailing list , "STARK, BARBARA H" Content-Type: multipart/alternative; boundary="00000000000067d0fa059c1d5396" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 14 Jan 2020 17:57:37 -0000 --00000000000067d0fa059c1d5396 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 11, 2020, 01:35 Stephane Bortzmeyer wrote: > On Thu, Jan 09, 2020 at 04:44:11PM +0000, > Livingood, Jason wrote > a message of 11 lines which said: > > > [JL] Perhaps we can simply solve the problem of how to provide a > > standards-based mechanism to communicate structured data to a client > > about things such as how a resolver operates (e.g. DNSSEC > > validating, DoH URL of X, DOT FQDN of Y, whatever). How the app will > > choose to use that information and make a selection decision seems > > up to the app/OS. > That's tempting (although I suspect there will be some pressures to > force applications to follow blindly these signals from the access > network, thus depriving the end user of a real choice, but I digress.) > What sort of pressures are you talking about? > But isn't it already done in the PvD project? > https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000067d0fa059c1d5396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 11, 2020, 01:35 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Thu, Jan 09, 2020 at 04:44:11PM +0000,<= br> =C2=A0Livingood, Jason <Jason_Livingood@comcast.com> wro= te
=C2=A0a message of 11 lines which said:

> [JL] Perhaps we can simply solve the problem of how to provide a
> standards-based mechanism to communicate structured data to a client > about things such as how a resolver operates (e.g. DNSSEC
> validating, DoH URL of X, DOT FQDN of Y, whatever). How the app will > choose to use that information and make a selection decision seems
> up to the app/OS.

That's tempting (although I suspect there will be some pressures to
force applications to follow blindly these signals from the access
network, thus depriving the end user of a real choice, but I digress.)
<= /blockquote>

What = sort of pressures are you talking about?

<= div dir=3D"auto">

But isn't it already done in the PvD project?
https://datatrac= ker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/


--
Add mailing list
Add@ie= tf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000067d0fa059c1d5396-- From nobody Tue Jan 14 13:43:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A071512010C for ; Tue, 14 Jan 2020 13:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJgFTA6hy1DK for ; Tue, 14 Jan 2020 13:43:52 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 99D03120059 for ; Tue, 14 Jan 2020 13:43:52 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id z8so15569270ioh.0 for ; Tue, 14 Jan 2020 13:43:52 -0800 (PST) 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=JaTQoFsbBSA+Uxn2OWv6Kur7RiBHCtAZKE+8h/Z3+5Q=; b=MnjaRfs1LPdhdVOTRx1dyPog72PM26fYx+CIcMBk6WPG6Og5+U7QSMKIMXfI1a0SH8 OVkLEjGdE6d8gCeU0nvVwexYkubRWpwxklcjvOKBMkgYqPQ+8mHkhK0vmN97e2uROmUh D+87KX5QMsiFzD/Pw2PvnNSLV+IHMBi2j4OuQS2ITfwpX0yoKLI2fpisraFEFEa80YHB dUlwvqDdWMRrtKB/7lzJwDLXB2S2cGHfBiAV6tNAEwpoF5HX2gov/tmr7jJl0A5hsP0H A0gFiktbMuYYwAcuRxdvvojAHI4XTabkAP4RqvoFx8IssEhi4fv4ZzMyeaKaB3hsxFU6 jOpg== 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=JaTQoFsbBSA+Uxn2OWv6Kur7RiBHCtAZKE+8h/Z3+5Q=; b=Fsvp9tOvLOeXlVzS0gUmNVnlZ/KIPB+Z7KO8Md7EYDw2Bn62Mwbef2IqtaL9QrnNje Ceo3PzT+6xXIn8dTRZuj2WhfBzvzyBCItmgGchYq6LKclDa00MjfL/i7yU1CtxnVCDtG nGsSUlmUePh5+ArxeR9ZS0rqsKMWgoR3eKR65DZNxLlELjEOZbaEPSwROczc5JFA+V7l SxA7Br7hyGkEKfW/QEda3hkFL3cWDGXbXSvz4CDtMOQWMd+VY4FjMtCaJqdr3NLt9HnZ /TnAaTCcPdFfgHIwZMfXlp1moFlymN1O+Phl2wvvwHRRWeRaY/DhaKQ6GeeoxKeJ/HYV jSpA== X-Gm-Message-State: APjAAAXhJ0EBZM+JevyA6P9c2khz+y75fBov/hBMn4Di45r5zHPR+Z/1 g6mZMwJLYUfhV+k853Qfwnil9aJJcp0N/Qj/RhJOesWW9mE= X-Google-Smtp-Source: APXvYqyU0CzmGRliTXQPPgfhhJCQsISuJjYX+rlSabi9sLDJp6COzjLenzDK/mxMEBVAQJrHH5vPJbeb8ac3OGzjC/E= X-Received: by 2002:a5d:80d6:: with SMTP id h22mr7520407ior.129.1579038231573; Tue, 14 Jan 2020 13:43:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 14 Jan 2020 16:43:39 -0500 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Ted Lemon , Alissa Cooper , ADD Mailing list , =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= , Stephen Farrell Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ea6091059c207c8f" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 14 Jan 2020 21:43:55 -0000 --000000000000ea6091059c207c8f Content-Type: multipart/alternative; boundary="000000000000e1876c059c207c53" --000000000000e1876c059c207c53 Content-Type: text/plain; charset="UTF-8" Thanks for attempting a consensus charter, Glenn. Some comments inline. On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: ... > Proposed Working Group Charter ... > > Network operators that start offering DNS encryption on their servers > need a way to indicate this support to clients. Beyond support for > encrypted DNS, local networks may also have policy about the use of DNS > to non-local DNS servers. Communicating such network policy to clients > would allow clients to make more informed decisions about which DNS > servers to use. I feel strongly that we should avoid "policy" in the WG scope text. We appear to lack a shared understanding of what this word means, and it is the focus of much conflict here. Including it here seems like a recipe for confrontation within the working group. I also don't think it's necessary for almost any of the goals mentioned on this list: we can rephrase in a way that is both clearer and more broadly acceptable. In this case, I would suggest: "... servers need a way to indicate this support to clients. Clients may also be able to make better decisions about which DNS servers to use if they can learn more about the resolution behaviors of each server.". > The Adaptive DNS Discovery (ADD) working group will define mechanisms and > protocols to: ... > - allow network providers to communicate DNS policy to clients, > including information about locally-accessible names; In this case, I would rephrase as "... communicate information about resolver behavior to clients, including ...". ... > Any mechanisms that specify interactions between clients and > servers must provide the security properties expected of IETF > protocols, e.g., confidentiality protection, integrity protection, > and authentication with strong work factor. This appears to rule out opportunistic upgrade to DoH, as well as the entire RESINFO framework adopted by DNSOP. Personally, I don't think "the security properties expected of IETF protocols" are compatible with most of the use cases we've discussed, including the ones mentioned in this charter text. I think we would be better off flipping this to explicitly focus on opportunistic protocols, and promise to document appropriate guardrails against improper reliance on security properties that are not provided. While opportunistic security is not to be relied on for crucial security properties, I think opportunistic privacy (against a passive adversary) is valuable and worth including in the working group's scope. Also, opportunistic upgrade would give clients a clear indication that they are speaking directly to a modern resolver, allowing them to rely on modern DNS features. In the absence of such a signal, clients cannot rely on any DNS features beyond basic A/AAAA queries, due to the lingering deployment of buggy resolvers, forwarders, and middleboxes. I know that this has been a major factor in popular clients' decisions not to make use of EDNS, DNSSEC, and other modern DNS features. > --000000000000e1876c059c207c53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for attempting a consensus charter, Glenn.=C2=A0 So= me comments inline.

On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCU= niversal) <Glenn.Deen@nbcuni.co= m> wrote:
...
> Proposed Working Group Charter
... =C2= =A0
>
> Network operators that start offering DNS encryption on= their servers
> need a way to indicate this support to clients. Beyo= nd support for
> encrypted DNS, local networks may also have policy a= bout the use of DNS
> to non-local DNS servers. Communicating such ne= twork policy to clients
> would allow clients to make more informed d= ecisions about which DNS
> servers to use.

I feel strongly tha= t we should avoid "policy" in the WG scope text.=C2=A0 We appear = to lack a shared understanding of what this word means, and it is the focus= of much conflict here.=C2=A0 Including it here seems like a recipe for con= frontation within the working group.=C2=A0 I also don't think it's = necessary for almost any of the goals mentioned on this list: we can rephra= se in a way that is both clearer and more broadly acceptable.

In this case, I would suggest: "... servers need a way to indica= te this support to clients.=C2=A0 Clients may also be able to make better d= ecisions about which DNS servers to use if they can learn more about the re= solution behaviors of each server.".

> The Adaptive DNS= Discovery (ADD) working group will define mechanisms and
> protocols= to:
...
> - allow network providers to communicate DNS pol= icy to clients,
> including information about locally-accessible name= s;

In this case, I would rephrase as "... com= municate information about resolver behavior to clients, including ..."= ;.

...
> Any mechanisms that specify interaction= s between clients and
> servers must provide the security properties = expected of IETF
> protocols, e.g., confidentiality protection, integ= rity protection,
> and authentication with strong work factor.
<= div>
This appears to rule out opportunistic upgrade to DoH, a= s well as the entire RESINFO framework adopted by DNSOP.=C2=A0 Personally, = I don't think "the security properties expected of IETF protocols&= quot; are compatible with most of the use cases we've discussed, includ= ing the ones mentioned in this charter text.=C2=A0 I think we would be bett= er off flipping this to explicitly focus on opportunistic protocols, and pr= omise to document appropriate guardrails against improper reliance on secur= ity properties that are not provided.

While opport= unistic security is not to be relied on for crucial security properties, I = think opportunistic privacy (against a passive adversary) is=C2=A0valuable = and worth including in the working group's scope.=C2=A0 Also, opportuni= stic upgrade would give clients a clear indication that they are speaking d= irectly to a modern resolver, allowing them to rely on modern DNS features.= =C2=A0 In the absence of such a signal, clients cannot rely on any DNS feat= ures beyond basic A/AAAA queries, due to the lingering deployment of buggy = resolvers, forwarders, and middleboxes.=C2=A0 I know that this has been a m= ajor factor in popular clients'=C2=A0decisions not to make use of EDNS,= DNSSEC, and other modern DNS features.
<= div>
--000000000000e1876c059c207c53-- --000000000000ea6091059c207c8f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCB2eoNt4kwVdRdeJuN83HwPPTMIJTyai5Wknczu3UXg7TAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAxMTQyMTQzNTJaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAgq/yx50GoBqzq5R2QxucfZx7YqtrmbBhxUeMySCX3Q9bVE1btGHfPYFq9Uxmpiqmke70yJtw P2JaCKaQInZv4bZpyLkiyIAyUNCHNjVTf0a0a6HN0vhNjNOMZBn2p0sEb3U/A0LpV2JPY10lVO5x PfdYon2INTcRbEutXzes4JUsvSXTWDsnSjVLc+OOS0Xl+OMah5U3T03/OWBToqRWX3w7+Feu6gxi XzmAzD+P12l7pZt4q5LMr8jX6McmdMt/DPW9Omar4sGZS7ahE4u7jz8kiixXAJwOQDJDq6mkbQkZ stAaS9qYNardF6poGaxkO9ZbXfTrIhdOpH7HcCoiTA== --000000000000ea6091059c207c8f-- From nobody Tue Jan 14 14:38:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DDE120059 for ; Tue, 14 Jan 2020 14:38:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8WvtM_yhbmZU for ; Tue, 14 Jan 2020 14:38:27 -0800 (PST) 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 C2386120046 for ; Tue, 14 Jan 2020 14:38:27 -0800 (PST) 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 00EMb7rn004255 for ; Tue, 14 Jan 2020 14:38:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=g0YSG0OcdULESS0qLzCweEp8IiZodZg8n1nHZxDAilQ=; b=dp19WpetHE5WOZKQvBszTZuoDa1CIKlm69qyiz3sDN16xAtXYl11AWtDaOSqBSms7pg+ m1mBwJZIAa/R+jw05wnnnxe2yNx+Iv5KHDDKRpXajACgUAx+70rcYllo2ae2p+DGboMX G9v8jVglk0GXaFpeVEUwVkolS/pshtNo+x4oc6jp0BT8uJDLpgQywgn77luN71g2q7zz E6uMIxdHXXoNrbLY5B8nMC/OAtQIB4D1x+mZ3gNEhurFba22z6T0vnXV1ayP66CZNBs0 gaeQmmha0eeB99SbNh9FMaS6S9w6IIzYLNc1w8PzVsFTvlkYpQ4xJI4M9GAhMRD3fNt4 AQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2xfyfpj6xa-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 14 Jan 2020 14:38:26 -0800 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4400F9PC80OR20@ma1-mtap-s03.corp.apple.com> for add@ietf.org; Tue, 14 Jan 2020 14:38:24 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4400B00BCYO600@nwk-mmpp-sz09.apple.com> for add@ietf.org; Tue, 14 Jan 2020 14:38:24 -0800 (PST) X-Va-A: X-Va-T-CD: 221abde68e6359e30a5cccbd17ef49f2 X-Va-E-CD: 3fcfe56601761e8bdddefe209b9584a6 X-Va-R-CD: f4304487b877ba5f48840d6d4e04541f X-Va-CD: 0 X-Va-ID: 0a453c92-fd5b-4f98-9ec3-73a77cd119ed X-V-A: X-V-T-CD: 221abde68e6359e30a5cccbd17ef49f2 X-V-E-CD: 3fcfe56601761e8bdddefe209b9584a6 X-V-R-CD: f4304487b877ba5f48840d6d4e04541f X-V-CD: 0 X-V-ID: eaaf7026-9e8f-4dd0-8837-5843aaac101b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-14_06:,, signatures=0 Received: from [17.234.71.35] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q44008HFC7ZWZ70@nwk-mmpp-sz09.apple.com> for add@ietf.org; Tue, 14 Jan 2020 14:38:24 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Message-id: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Date: Tue, 14 Jan 2020 14:38:21 -0800 To: ADD Mailing list X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-14_06:, , signatures=0 Archived-At: Subject: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 14 Jan 2020 22:38:29 -0000 Hi all, I wanted to share an updated proposal for an ADD charter, based on the = feedback and discussion on the list in the past several weeks. This is based on the original proposal that was sent in December, taking = into account various comments and suggestions. Glenn Deen, Andrew = Campling, and I worked on this revision together and came to consensus = on its contents. Thoughts and comments are welcome as always! (Note that the proposed name of the group was not changed, and is = entirely open to bikeshedding. Naming is hard!) Best, Tommy Adaptive DNS Discovery (ADD) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposed Working Group Charter Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits. This working group will focus on discovery and selection of DNS = resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs; supporting both encrypted and unencrypted resolvers. Clients adopting encrypted DNS protocols need to determine which DNS servers support encrypted transports, and which server to use for = specific queries if multiple servers are available. These decisions can vary = based on the network environment, and also based on the content and purpose of the client queries. Network operators that start offering DNS encryption on their servers = also need a way to indicate this support to clients. Communicating = information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a = resolver may be able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the = following deliverables: - define a mechanism that allows clients to discover DNS resolvers, including encrypted DNS servers, that are available to the client either on the public Internet or on private or local networks; - define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions; - develop an informational document that describes how client applications and systems can manage selection of DNS resolvers in various network environments and use cases. Any mechanisms that specify interactions between clients and servers must provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor. This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols. It will also work with capport to ensure that solutions are applicable to captive networks. From nobody Tue Jan 14 14:43:40 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6854512008F for ; Tue, 14 Jan 2020 14:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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_LOW=-0.7, 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 (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOgxasXoI7lr for ; Tue, 14 Jan 2020 14:43:36 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (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 A3A24120046 for ; Tue, 14 Jan 2020 14:43:36 -0800 (PST) Received: from pps.filterd (m0048207.ppops.net [127.0.0.1]) by m0048207.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 00EMgMnO042446 for ; Tue, 14 Jan 2020 17:43:35 -0500 Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0048207.ppops.net-00176a04. with ESMTP id 2xfagjhhs6-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 14 Jan 2020 17:43:35 -0500 Received: from unknown (HELO ashemwp00006.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 14 Jan 2020 14:43:33 -0800 Received: from ashemwp00047.mail.tfayd.com (100.126.24.71) by ashemwp00033.mail.tfayd.com (100.126.24.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 14 Jan 2020 17:43:29 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00047.mail.tfayd.com (100.126.24.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 14 Jan 2020 17:43:29 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Tue, 14 Jan 2020 17:43:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pf0//OiYZzKMTOauSx6cPAWhtmFFkHbmQAg0eSWsMCell1uxS0OKiCQ2Nzga+J1IeQJkO2CcS+aOa1jhPX0R+TzdvHrQaV9k677S78M/nZDlpf2JPdxV4dDYnoT/bFtOsdmjVcoOUabgNqXsnfBWhhlClqvlUK15sWgFEPOyybKrBoyaSULXvGE4BDuW3mNs8DQ16q+BQaSGMD3i7iEJKFCn9WXxQwQeJmYxI/A3zLlqWKL8NQ+pVX5APJPQ77qRRZYWLYoXLVtu/uZJvnswciJpT4AryaOgjc8sglelcyU8MNCwognk8Vh5eTWPC70LRTVz6wb6EYUq80s8haE27Q== 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=UvuYGQxkEw6cIqO/FQ7F/93a6o5x6ntijejpHBLG/Mg=; b=NnyxMPqRgU+Z9j5jm3to+zjAGZkC8VJocb+31FQoR13hOmmSLlFt36ZqwOMZHBWVsTxUXVweyJMh2C0BhR8supBMiYtVPCg3RoKKkL/m8gblnW4bVY5J3HH0fcBXrRw96OOFn2lC0PDeFX02mDg5eouv97y4Zao3eFGEpGVvhQckzuPqb8TZ6ZWhKJSe1/3TVPDYC1zFrKuZKwVSopfDRs5WHNlgYZ8DIeN6PB65peoC30OJNAHDHQLoaCWUy5l8oV5DiBatsXy64GiWPW2eHBr8MZFQRsl+8d7oaWDQR+gwOZAcyLmVCRsyAW2NC716RyYGwrw9Eo552GrDhhGUnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UvuYGQxkEw6cIqO/FQ7F/93a6o5x6ntijejpHBLG/Mg=; b=x6Slpyxw6650upVPt+xr2J9vP9az65SiA12gUIxxeN60aVAItEcNBBtx+T6dV2QI2ayQ2Bt6yJT318KMNsIVp3K7gcktqx0aOs+AeUuPUGXvY0ywJpE8L1iGAdl0r4LNMesMqNikFl/yVq3ZoQLUtEMmJOWQA+s9EXghLUP9MLg= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB3129.namprd14.prod.outlook.com (20.179.163.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Tue, 14 Jan 2020 22:43:28 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.017; Tue, 14 Jan 2020 22:43:28 +0000 From: "Deen, Glenn (NBCUniversal)" To: Ben Schwartz CC: Ted Lemon , Alissa Cooper , "ADD Mailing list" , =?utf-8?B?IE1pcmphIEvDvGhsZXdpbmQgKElFVEYpIA==?= , Stephen Farrell Thread-Topic: [EXTERNAL] Re: [Add] A proposed charter for ABCD Thread-Index: AQHVxz9JmWuBpd+SzUuSPFqRPFm94qfquN6AgAAQtxE= Date: Tue, 14 Jan 2020 22:43:28 +0000 Message-ID: <619CE016-902E-4893-8CEA-76DB2AA78F51@nbcuni.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2600:387:8:f::3e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a65462d6-e701-49d3-6536-08d799432c64 x-ms-traffictypediagnostic: DM6PR14MB3129: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(2616005)(5660300002)(36756003)(478600001)(66556008)(66946007)(66446008)(66476007)(91956017)(64756008)(2906002)(76116006)(71200400001)(53546011)(186003)(54906003)(316002)(33656002)(6506007)(81166006)(8936002)(8676002)(6916009)(81156014)(86362001)(6486002)(4326008)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB3129; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n/UNWxFvFFGnrxt9Tt8p8R4rLxwX6xcBUTY7WobD59+KIjliTIPEM9a0B0qDKwxxtKV7VBA6L5CpsSHaNSlwkQR4igm9wyxG3NBDNuRuVWh4SBdiu8Wz7kI6S5fCcdkC6B8pm+FvegSEACcHvOIAeF1rRuRxoF6UAaa8C7o9iu5LgqsxvFMgtvs/9grgR/j90NaL1br5Zfz1fcGeZKsOXCuP7mF4I3Mg7EPLdcUo/7E4evd2MTSxRXZmAKqCRhAAiDBiJi+HRQcybJCygRm117wBENsS8oKRtkFfrWUB2YOlqBhaE44NzMBiZl5Ecn9zb/4LBG5KpEiyf+e6sREUwsxcBz0W7oOrr5/BfgHkbbDz14tQB4cCerB30pFaPmbDw/duZ2uRBq0oMwnnOgIAyRqWlfOwnEF0oVmVRUyqoc+5aKIEfJt9LOUV+ri261WX Content-Type: multipart/alternative; boundary="_000_619CE016902E48938CEA76DB2AA78F51nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a65462d6-e701-49d3-6536-08d799432c64 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 22:43:28.2113 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sYqA/r0nH7q3w79Nipx04BaMaKPdBArQbFYLv74mUpjO9OfHKKI8aYPhES7n9DEizp2Ycx4fAhh6P06Gz/tHTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB3129 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-14_06:2020-01-14, 2020-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 impostorscore=0 phishscore=0 spamscore=0 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001140174 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 14 Jan 2020 22:43:39 -0000 --_000_619CE016902E48938CEA76DB2AA78F51nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVuDQoNCkkgZnVsbHkgYWdyZWUgb24geW91ciBwb2ludCBhYm91dC4gSW4gdGhlIHVwZGF0ZSBU b21teSBqdXN0IHBvc3RlZCB3ZSBnb3QgcmlkIG9mIHRoZSBwb2xpY3kgd29yZCBhbGwgdG9nZXRo ZXIuDQoNClRvIHlvdXIgcG9pbnQgb24gb3Bwb3J0dW5pc3RpYywgSSBiZWxpZXZlIHRoZSB1cGRh dGVkIHByb3Bvc2FsIHdvdWxkIHBlcm1pdCB0aGF0Lg0KDQoNCg0KR2xlbm4NCg0KT24gSmFuIDE0 LCAyMDIwLCBhdCAxOjQ0IFBNLCBCZW4gU2Nod2FydHogPGJlbWFzY0Bnb29nbGUuY29tPiB3cm90 ZToNCg0K77u/DQpUaGFua3MgZm9yIGF0dGVtcHRpbmcgYSBjb25zZW5zdXMgY2hhcnRlciwgR2xl bm4uICBTb21lIGNvbW1lbnRzIGlubGluZS4NCg0KT24gVGh1LCBKYW4gOSwgMjAyMCBhdCA1OjU2 IFBNIERlZW4sIEdsZW5uIChOQkNVbml2ZXJzYWwpIDxHbGVubi5EZWVuQG5iY3VuaS5jb208bWFp bHRvOkdsZW5uLkRlZW5AbmJjdW5pLmNvbT4+IHdyb3RlOg0KLi4uDQo+IFByb3Bvc2VkIFdvcmtp bmcgR3JvdXAgQ2hhcnRlcg0KLi4uDQo+DQo+IE5ldHdvcmsgb3BlcmF0b3JzIHRoYXQgc3RhcnQg b2ZmZXJpbmcgRE5TIGVuY3J5cHRpb24gb24gdGhlaXIgc2VydmVycw0KPiBuZWVkIGEgd2F5IHRv IGluZGljYXRlIHRoaXMgc3VwcG9ydCB0byBjbGllbnRzLiBCZXlvbmQgc3VwcG9ydCBmb3INCj4g ZW5jcnlwdGVkIEROUywgbG9jYWwgbmV0d29ya3MgbWF5IGFsc28gaGF2ZSBwb2xpY3kgYWJvdXQg dGhlIHVzZSBvZiBETlMNCj4gdG8gbm9uLWxvY2FsIEROUyBzZXJ2ZXJzLiBDb21tdW5pY2F0aW5n IHN1Y2ggbmV0d29yayBwb2xpY3kgdG8gY2xpZW50cw0KPiB3b3VsZCBhbGxvdyBjbGllbnRzIHRv IG1ha2UgbW9yZSBpbmZvcm1lZCBkZWNpc2lvbnMgYWJvdXQgd2hpY2ggRE5TDQo+IHNlcnZlcnMg dG8gdXNlLg0KDQpJIGZlZWwgc3Ryb25nbHkgdGhhdCB3ZSBzaG91bGQgYXZvaWQgInBvbGljeSIg aW4gdGhlIFdHIHNjb3BlIHRleHQuICBXZSBhcHBlYXIgdG8gbGFjayBhIHNoYXJlZCB1bmRlcnN0 YW5kaW5nIG9mIHdoYXQgdGhpcyB3b3JkIG1lYW5zLCBhbmQgaXQgaXMgdGhlIGZvY3VzIG9mIG11 Y2ggY29uZmxpY3QgaGVyZS4gIEluY2x1ZGluZyBpdCBoZXJlIHNlZW1zIGxpa2UgYSByZWNpcGUg Zm9yIGNvbmZyb250YXRpb24gd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwLiAgSSBhbHNvIGRvbid0 IHRoaW5rIGl0J3MgbmVjZXNzYXJ5IGZvciBhbG1vc3QgYW55IG9mIHRoZSBnb2FscyBtZW50aW9u ZWQgb24gdGhpcyBsaXN0OiB3ZSBjYW4gcmVwaHJhc2UgaW4gYSB3YXkgdGhhdCBpcyBib3RoIGNs ZWFyZXIgYW5kIG1vcmUgYnJvYWRseSBhY2NlcHRhYmxlLg0KDQpJbiB0aGlzIGNhc2UsIEkgd291 bGQgc3VnZ2VzdDogIi4uLiBzZXJ2ZXJzIG5lZWQgYSB3YXkgdG8gaW5kaWNhdGUgdGhpcyBzdXBw b3J0IHRvIGNsaWVudHMuICBDbGllbnRzIG1heSBhbHNvIGJlIGFibGUgdG8gbWFrZSBiZXR0ZXIg ZGVjaXNpb25zIGFib3V0IHdoaWNoIEROUyBzZXJ2ZXJzIHRvIHVzZSBpZiB0aGV5IGNhbiBsZWFy biBtb3JlIGFib3V0IHRoZSByZXNvbHV0aW9uIGJlaGF2aW9ycyBvZiBlYWNoIHNlcnZlci4iLg0K DQo+IFRoZSBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpIHdvcmtpbmcgZ3JvdXAgd2lsbCBk ZWZpbmUgbWVjaGFuaXNtcyBhbmQNCj4gcHJvdG9jb2xzIHRvOg0KLi4uDQo+IC0gYWxsb3cgbmV0 d29yayBwcm92aWRlcnMgdG8gY29tbXVuaWNhdGUgRE5TIHBvbGljeSB0byBjbGllbnRzLA0KPiBp bmNsdWRpbmcgaW5mb3JtYXRpb24gYWJvdXQgbG9jYWxseS1hY2Nlc3NpYmxlIG5hbWVzOw0KDQpJ biB0aGlzIGNhc2UsIEkgd291bGQgcmVwaHJhc2UgYXMgIi4uLiBjb21tdW5pY2F0ZSBpbmZvcm1h dGlvbiBhYm91dCByZXNvbHZlciBiZWhhdmlvciB0byBjbGllbnRzLCBpbmNsdWRpbmcgLi4uIi4N Cg0KLi4uDQo+IEFueSBtZWNoYW5pc21zIHRoYXQgc3BlY2lmeSBpbnRlcmFjdGlvbnMgYmV0d2Vl biBjbGllbnRzIGFuZA0KPiBzZXJ2ZXJzIG11c3QgcHJvdmlkZSB0aGUgc2VjdXJpdHkgcHJvcGVy dGllcyBleHBlY3RlZCBvZiBJRVRGDQo+IHByb3RvY29scywgZS5nLiwgY29uZmlkZW50aWFsaXR5 IHByb3RlY3Rpb24sIGludGVncml0eSBwcm90ZWN0aW9uLA0KPiBhbmQgYXV0aGVudGljYXRpb24g d2l0aCBzdHJvbmcgd29yayBmYWN0b3IuDQoNClRoaXMgYXBwZWFycyB0byBydWxlIG91dCBvcHBv cnR1bmlzdGljIHVwZ3JhZGUgdG8gRG9ILCBhcyB3ZWxsIGFzIHRoZSBlbnRpcmUgUkVTSU5GTyBm cmFtZXdvcmsgYWRvcHRlZCBieSBETlNPUC4gIFBlcnNvbmFsbHksIEkgZG9uJ3QgdGhpbmsgInRo ZSBzZWN1cml0eSBwcm9wZXJ0aWVzIGV4cGVjdGVkIG9mIElFVEYgcHJvdG9jb2xzIiBhcmUgY29t cGF0aWJsZSB3aXRoIG1vc3Qgb2YgdGhlIHVzZSBjYXNlcyB3ZSd2ZSBkaXNjdXNzZWQsIGluY2x1 ZGluZyB0aGUgb25lcyBtZW50aW9uZWQgaW4gdGhpcyBjaGFydGVyIHRleHQuICBJIHRoaW5rIHdl IHdvdWxkIGJlIGJldHRlciBvZmYgZmxpcHBpbmcgdGhpcyB0byBleHBsaWNpdGx5IGZvY3VzIG9u IG9wcG9ydHVuaXN0aWMgcHJvdG9jb2xzLCBhbmQgcHJvbWlzZSB0byBkb2N1bWVudCBhcHByb3By aWF0ZSBndWFyZHJhaWxzIGFnYWluc3QgaW1wcm9wZXIgcmVsaWFuY2Ugb24gc2VjdXJpdHkgcHJv cGVydGllcyB0aGF0IGFyZSBub3QgcHJvdmlkZWQuDQoNCldoaWxlIG9wcG9ydHVuaXN0aWMgc2Vj dXJpdHkgaXMgbm90IHRvIGJlIHJlbGllZCBvbiBmb3IgY3J1Y2lhbCBzZWN1cml0eSBwcm9wZXJ0 aWVzLCBJIHRoaW5rIG9wcG9ydHVuaXN0aWMgcHJpdmFjeSAoYWdhaW5zdCBhIHBhc3NpdmUgYWR2 ZXJzYXJ5KSBpcyB2YWx1YWJsZSBhbmQgd29ydGggaW5jbHVkaW5nIGluIHRoZSB3b3JraW5nIGdy b3VwJ3Mgc2NvcGUuICBBbHNvLCBvcHBvcnR1bmlzdGljIHVwZ3JhZGUgd291bGQgZ2l2ZSBjbGll bnRzIGEgY2xlYXIgaW5kaWNhdGlvbiB0aGF0IHRoZXkgYXJlIHNwZWFraW5nIGRpcmVjdGx5IHRv IGEgbW9kZXJuIHJlc29sdmVyLCBhbGxvd2luZyB0aGVtIHRvIHJlbHkgb24gbW9kZXJuIEROUyBm ZWF0dXJlcy4gIEluIHRoZSBhYnNlbmNlIG9mIHN1Y2ggYSBzaWduYWwsIGNsaWVudHMgY2Fubm90 IHJlbHkgb24gYW55IEROUyBmZWF0dXJlcyBiZXlvbmQgYmFzaWMgQS9BQUFBIHF1ZXJpZXMsIGR1 ZSB0byB0aGUgbGluZ2VyaW5nIGRlcGxveW1lbnQgb2YgYnVnZ3kgcmVzb2x2ZXJzLCBmb3J3YXJk ZXJzLCBhbmQgbWlkZGxlYm94ZXMuICBJIGtub3cgdGhhdCB0aGlzIGhhcyBiZWVuIGEgbWFqb3Ig ZmFjdG9yIGluIHBvcHVsYXIgY2xpZW50cycgZGVjaXNpb25zIG5vdCB0byBtYWtlIHVzZSBvZiBF RE5TLCBETlNTRUMsIGFuZCBvdGhlciBtb2Rlcm4gRE5TIGZlYXR1cmVzLg0K --_000_619CE016902E48938CEA76DB2AA78F51nbcunicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj5CZW48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRp diBkaXI9Imx0ciI+SSBmdWxseSBhZ3JlZSBvbiB5b3VyIHBvaW50IGFib3V0LiBJbiB0aGUgdXBk YXRlIFRvbW15IGp1c3QgcG9zdGVkIHdlIGdvdCByaWQgb2YgdGhlIHBvbGljeSB3b3JkIGFsbCB0 b2dldGhlci4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBk aXI9Imx0ciI+VG8geW91ciBwb2ludCBvbiBvcHBvcnR1bmlzdGljLCBJIGJlbGlldmUgdGhlIHVw ZGF0ZWQgcHJvcG9zYWwgd291bGQgcGVybWl0IHRoYXQuJm5ic3A7PC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5HbGVubiZuYnNwOzwvZGl2Pg0KPGRp diBkaXI9Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+T24gSmFuIDE0LCAyMDIw LCBhdCAxOjQ0IFBNLCBCZW4gU2Nod2FydHogJmx0O2JlbWFzY0Bnb29nbGUuY29tJmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2IGRpcj0ibHRyIj5UaGFua3MgZm9yIGF0dGVt cHRpbmcgYSBjb25zZW5zdXMgY2hhcnRlciwgR2xlbm4uJm5ic3A7IFNvbWUgY29tbWVudHMgaW5s aW5lLjxicj4NCjxicj4NCk9uIFRodSwgSmFuIDksIDIwMjAgYXQgNTo1NiBQTSBEZWVuLCBHbGVu biAoTkJDVW5pdmVyc2FsKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkdsZW5uLkRlZW5AbmJjdW5pLmNv bSI+R2xlbm4uRGVlbkBuYmN1bmkuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KLi4uIDxicj4NCiZn dDsgUHJvcG9zZWQgV29ya2luZyBHcm91cCBDaGFydGVyPGJyPg0KLi4uICZuYnNwOzxicj4NCiZn dDs8YnI+DQomZ3Q7IE5ldHdvcmsgb3BlcmF0b3JzIHRoYXQgc3RhcnQgb2ZmZXJpbmcgRE5TIGVu Y3J5cHRpb24gb24gdGhlaXIgc2VydmVyczxicj4NCiZndDsgbmVlZCBhIHdheSB0byBpbmRpY2F0 ZSB0aGlzIHN1cHBvcnQgdG8gY2xpZW50cy4gQmV5b25kIHN1cHBvcnQgZm9yPGJyPg0KJmd0OyBl bmNyeXB0ZWQgRE5TLCBsb2NhbCBuZXR3b3JrcyBtYXkgYWxzbyBoYXZlIHBvbGljeSBhYm91dCB0 aGUgdXNlIG9mIEROUzxicj4NCiZndDsgdG8gbm9uLWxvY2FsIEROUyBzZXJ2ZXJzLiBDb21tdW5p Y2F0aW5nIHN1Y2ggbmV0d29yayBwb2xpY3kgdG8gY2xpZW50czxicj4NCiZndDsgd291bGQgYWxs b3cgY2xpZW50cyB0byBtYWtlIG1vcmUgaW5mb3JtZWQgZGVjaXNpb25zIGFib3V0IHdoaWNoIERO Uzxicj4NCiZndDsgc2VydmVycyB0byB1c2UuPGJyPg0KPGJyPg0KSSBmZWVsIHN0cm9uZ2x5IHRo YXQgd2Ugc2hvdWxkIGF2b2lkICZxdW90O3BvbGljeSZxdW90OyBpbiB0aGUgV0cgc2NvcGUgdGV4 dC4mbmJzcDsgV2UgYXBwZWFyIHRvIGxhY2sgYSBzaGFyZWQgdW5kZXJzdGFuZGluZyBvZiB3aGF0 IHRoaXMgd29yZCBtZWFucywgYW5kIGl0IGlzIHRoZSBmb2N1cyBvZiBtdWNoIGNvbmZsaWN0IGhl cmUuJm5ic3A7IEluY2x1ZGluZyBpdCBoZXJlIHNlZW1zIGxpa2UgYSByZWNpcGUgZm9yIGNvbmZy b250YXRpb24gd2l0aGluIHRoZSB3b3JraW5nIGdyb3VwLiZuYnNwOw0KIEkgYWxzbyBkb24ndCB0 aGluayBpdCdzIG5lY2Vzc2FyeSBmb3IgYWxtb3N0IGFueSBvZiB0aGUgZ29hbHMgbWVudGlvbmVk IG9uIHRoaXMgbGlzdDogd2UgY2FuIHJlcGhyYXNlIGluIGEgd2F5IHRoYXQgaXMgYm90aCBjbGVh cmVyIGFuZCBtb3JlIGJyb2FkbHkgYWNjZXB0YWJsZS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkluIHRoaXMgY2FzZSwgSSB3b3VsZCBzdWdnZXN0OiAmcXVvdDsuLi4gc2VydmVycyBuZWVkIGEg d2F5IHRvIGluZGljYXRlIHRoaXMgc3VwcG9ydCB0byBjbGllbnRzLiZuYnNwOyBDbGllbnRzIG1h eSBhbHNvIGJlIGFibGUgdG8gbWFrZSBiZXR0ZXIgZGVjaXNpb25zIGFib3V0IHdoaWNoIEROUyBz ZXJ2ZXJzIHRvIHVzZSBpZiB0aGV5IGNhbiBsZWFybiBtb3JlIGFib3V0IHRoZSByZXNvbHV0aW9u IGJlaGF2aW9ycyBvZiBlYWNoIHNlcnZlci4mcXVvdDsuPGJyPg0KPGRpdj48YnI+DQomZ3Q7IFRo ZSBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUg bWVjaGFuaXNtcyBhbmQ8YnI+DQomZ3Q7IHByb3RvY29scyB0bzo8YnI+DQouLi48L2Rpdj4NCjxk aXY+Jmd0OyAtIGFsbG93IG5ldHdvcmsgcHJvdmlkZXJzIHRvIGNvbW11bmljYXRlIEROUyBwb2xp Y3kgdG8gY2xpZW50cyw8YnI+DQomZ3Q7IGluY2x1ZGluZyBpbmZvcm1hdGlvbiBhYm91dCBsb2Nh bGx5LWFjY2Vzc2libGUgbmFtZXM7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiB0 aGlzIGNhc2UsIEkgd291bGQgcmVwaHJhc2UgYXMgJnF1b3Q7Li4uIGNvbW11bmljYXRlIGluZm9y bWF0aW9uIGFib3V0IHJlc29sdmVyIGJlaGF2aW9yIHRvIGNsaWVudHMsIGluY2x1ZGluZyAuLi4m cXVvdDsuPC9kaXY+DQo8ZGl2Pjxicj4NCi4uLjwvZGl2Pg0KPGRpdj4mZ3Q7IEFueSBtZWNoYW5p c21zIHRoYXQgc3BlY2lmeSBpbnRlcmFjdGlvbnMgYmV0d2VlbiBjbGllbnRzIGFuZDxicj4NCiZn dDsgc2VydmVycyBtdXN0IHByb3ZpZGUgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgZXhwZWN0ZWQg b2YgSUVURjxicj4NCiZndDsgcHJvdG9jb2xzLCBlLmcuLCBjb25maWRlbnRpYWxpdHkgcHJvdGVj dGlvbiwgaW50ZWdyaXR5IHByb3RlY3Rpb24sPGJyPg0KJmd0OyBhbmQgYXV0aGVudGljYXRpb24g d2l0aCBzdHJvbmcgd29yayBmYWN0b3IuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGlzIGFwcGVhcnMgdG8gcnVsZSBvdXQgb3Bwb3J0dW5pc3RpYyB1cGdyYWRlIHRvIERvSCwgYXMg d2VsbCBhcyB0aGUgZW50aXJlIFJFU0lORk8gZnJhbWV3b3JrIGFkb3B0ZWQgYnkgRE5TT1AuJm5i c3A7IFBlcnNvbmFsbHksIEkgZG9uJ3QgdGhpbmsgJnF1b3Q7dGhlIHNlY3VyaXR5IHByb3BlcnRp ZXMgZXhwZWN0ZWQgb2YgSUVURiBwcm90b2NvbHMmcXVvdDsgYXJlIGNvbXBhdGlibGUgd2l0aCBt b3N0IG9mIHRoZSB1c2UgY2FzZXMgd2UndmUgZGlzY3Vzc2VkLA0KIGluY2x1ZGluZyB0aGUgb25l cyBtZW50aW9uZWQgaW4gdGhpcyBjaGFydGVyIHRleHQuJm5ic3A7IEkgdGhpbmsgd2Ugd291bGQg YmUgYmV0dGVyIG9mZiBmbGlwcGluZyB0aGlzIHRvIGV4cGxpY2l0bHkgZm9jdXMgb24gb3Bwb3J0 dW5pc3RpYyBwcm90b2NvbHMsIGFuZCBwcm9taXNlIHRvIGRvY3VtZW50IGFwcHJvcHJpYXRlIGd1 YXJkcmFpbHMgYWdhaW5zdCBpbXByb3BlciByZWxpYW5jZSBvbiBzZWN1cml0eSBwcm9wZXJ0aWVz IHRoYXQgYXJlIG5vdCBwcm92aWRlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pldo aWxlIG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaXMgbm90IHRvIGJlIHJlbGllZCBvbiBmb3IgY3J1 Y2lhbCBzZWN1cml0eSBwcm9wZXJ0aWVzLCBJIHRoaW5rIG9wcG9ydHVuaXN0aWMgcHJpdmFjeSAo YWdhaW5zdCBhIHBhc3NpdmUgYWR2ZXJzYXJ5KSBpcyZuYnNwO3ZhbHVhYmxlIGFuZCB3b3J0aCBp bmNsdWRpbmcgaW4gdGhlIHdvcmtpbmcgZ3JvdXAncyBzY29wZS4mbmJzcDsgQWxzbywgb3Bwb3J0 dW5pc3RpYyB1cGdyYWRlIHdvdWxkIGdpdmUgY2xpZW50cw0KIGEgY2xlYXIgaW5kaWNhdGlvbiB0 aGF0IHRoZXkgYXJlIHNwZWFraW5nIGRpcmVjdGx5IHRvIGEgbW9kZXJuIHJlc29sdmVyLCBhbGxv d2luZyB0aGVtIHRvIHJlbHkgb24gbW9kZXJuIEROUyBmZWF0dXJlcy4mbmJzcDsgSW4gdGhlIGFi c2VuY2Ugb2Ygc3VjaCBhIHNpZ25hbCwgY2xpZW50cyBjYW5ub3QgcmVseSBvbiBhbnkgRE5TIGZl YXR1cmVzIGJleW9uZCBiYXNpYyBBL0FBQUEgcXVlcmllcywgZHVlIHRvIHRoZSBsaW5nZXJpbmcg ZGVwbG95bWVudCBvZg0KIGJ1Z2d5IHJlc29sdmVycywgZm9yd2FyZGVycywgYW5kIG1pZGRsZWJv eGVzLiZuYnNwOyBJIGtub3cgdGhhdCB0aGlzIGhhcyBiZWVuIGEgbWFqb3IgZmFjdG9yIGluIHBv cHVsYXIgY2xpZW50cycmbmJzcDtkZWNpc2lvbnMgbm90IHRvIG1ha2UgdXNlIG9mIEVETlMsIERO U1NFQywgYW5kIG90aGVyIG1vZGVybiBETlMgZmVhdHVyZXMuPC9kaXY+DQo8ZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRp dj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_619CE016902E48938CEA76DB2AA78F51nbcunicom_-- From nobody Tue Jan 14 14:46:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9734120831 for ; Tue, 14 Jan 2020 14:46:10 -0800 (PST) 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, 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hE5XS0K7jv30 for ; Tue, 14 Jan 2020 14:46:09 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 10AE6120059 for ; Tue, 14 Jan 2020 14:46:09 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 00EMgN5s024385; Tue, 14 Jan 2020 14:45:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=pWSmrR2gSdWm6UjlNmn1zvVcP1ZLCKmctWdcv4I7nno=; b=WvcSr7X+D3V3oo4tU5+qTib6A4FcLszXXYA8l1A7OjaHHbh26vMFYrD9nZCS9w9rZXaG NIxrW/vvfhMVNGxvebnD3M8ZllV+me1cA/KDw2ommyaacL4veFeQpl3YBfx2V52M5BLN 5lmHnUV+5EMT3KRhKSsY0RbQzbkAq/AUlW1XVVcOkI4NYUpMbnwBU842tX24qlOd8YmK bQQhAXC+eT5EJUIC+RwMspg/k4MscFP7dqSA9/E5bDRtaVefBh38Ma3xOpE7lVFUriIO 8C4ue/coID1FXey7kJcVm9fnVEq/aTBQ2lZkPyYJwQ74qTFpWaE4BJJSXdOhAVdSm4u1 ew== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2xfdw73wtr-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Jan 2020 14:45:59 -0800 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q4400IDYCKLM120@mr2-mtap-s03.rno.apple.com>; Tue, 14 Jan 2020 14:45:58 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q4400700CIEW100@nwk-mmpp-sz09.apple.com>; Tue, 14 Jan 2020 14:45:57 -0800 (PST) X-Va-A: X-Va-T-CD: 4ecbc541c651d4150af7dae7412fcbdc X-Va-E-CD: 3b057decf2847b632b89ebbbdae31b6a X-Va-R-CD: f72447924befeb80c3b03e1610ab2790 X-Va-CD: 0 X-Va-ID: d322781d-0a1c-4d67-ac90-8321aed65c3c X-V-A: X-V-T-CD: 4ecbc541c651d4150af7dae7412fcbdc X-V-E-CD: 3b057decf2847b632b89ebbbdae31b6a X-V-R-CD: f72447924befeb80c3b03e1610ab2790 X-V-CD: 0 X-V-ID: 9e474dc0-1a99-485e-adaf-99f1a353cf89 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-14_06:,, signatures=0 Received: from [17.234.71.35] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q4400M0TCKKC340@nwk-mmpp-sz09.apple.com>; Tue, 14 Jan 2020 14:45:57 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_D5ED3C31-CCF5-4FC8-8963-BB4DA752AB30" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Tue, 14 Jan 2020 14:45:53 -0800 In-reply-to: Cc: "Deen, Glenn (NBCUniversal)" , Alissa Cooper , ADD Mailing list , Ted Lemon , =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= , Stephen Farrell To: Ben Schwartz References: X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-14_06:, , signatures=0 Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 14 Jan 2020 22:46:11 -0000 --Apple-Mail=_D5ED3C31-CCF5-4FC8-8963-BB4DA752AB30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ben, As a note, Glenn and I worked on a revision of this today that I have = sent out to the list that should cover most of your comments. Anything specifically naming "policy" has been removed throughout the = charter proposal. We did toss around the idea of "resolver behavior" but = ended up being a bit more general in referring to information about the = resolver, that can be used in resolver selection. The main goal here is = to provide a communication mechanism in the IETF spec for properties = that describe what a resolver will serve, the most concrete example of = which is information about serving split DNS names. This communication = mechanism could be used for "policy" or "behavior" information, but that = would certainly be out of scope for this working group. With regards to the text for "security properties", this mainly came = from boilerplate security charter text. I don't read that as necessarily = ruling out opportunistic use of encryption as a strategy, but any = communication of explicit information between two parties (servers and = clients in this example) should be specified to be secure. I would argue = that just trying DoH to a given address does give you the security = properties of HTTPS when you use that; but that's also not any new = protocol mechanism. Best, Tommy > On Jan 14, 2020, at 1:43 PM, Ben Schwartz = wrote: >=20 > Thanks for attempting a consensus charter, Glenn. Some comments = inline. >=20 > On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCUniversal) = > wrote: > ...=20 > > Proposed Working Group Charter > ... =20 > > > > Network operators that start offering DNS encryption on their = servers > > need a way to indicate this support to clients. Beyond support for > > encrypted DNS, local networks may also have policy about the use of = DNS > > to non-local DNS servers. Communicating such network policy to = clients > > would allow clients to make more informed decisions about which DNS > > servers to use. >=20 > I feel strongly that we should avoid "policy" in the WG scope text. = We appear to lack a shared understanding of what this word means, and it = is the focus of much conflict here. Including it here seems like a = recipe for confrontation within the working group. I also don't think = it's necessary for almost any of the goals mentioned on this list: we = can rephrase in a way that is both clearer and more broadly acceptable. >=20 > In this case, I would suggest: "... servers need a way to indicate = this support to clients. Clients may also be able to make better = decisions about which DNS servers to use if they can learn more about = the resolution behaviors of each server.". >=20 > > The Adaptive DNS Discovery (ADD) working group will define = mechanisms and > > protocols to: > ... > > - allow network providers to communicate DNS policy to clients, > > including information about locally-accessible names; >=20 > In this case, I would rephrase as "... communicate information about = resolver behavior to clients, including ...". >=20 > ... > > Any mechanisms that specify interactions between clients and > > servers must provide the security properties expected of IETF > > protocols, e.g., confidentiality protection, integrity protection, > > and authentication with strong work factor. >=20 > This appears to rule out opportunistic upgrade to DoH, as well as the = entire RESINFO framework adopted by DNSOP. Personally, I don't think = "the security properties expected of IETF protocols" are compatible with = most of the use cases we've discussed, including the ones mentioned in = this charter text. I think we would be better off flipping this to = explicitly focus on opportunistic protocols, and promise to document = appropriate guardrails against improper reliance on security properties = that are not provided. >=20 > While opportunistic security is not to be relied on for crucial = security properties, I think opportunistic privacy (against a passive = adversary) is valuable and worth including in the working group's scope. = Also, opportunistic upgrade would give clients a clear indication that = they are speaking directly to a modern resolver, allowing them to rely = on modern DNS features. In the absence of such a signal, clients cannot = rely on any DNS features beyond basic A/AAAA queries, due to the = lingering deployment of buggy resolvers, forwarders, and middleboxes. I = know that this has been a major factor in popular clients' decisions not = to make use of EDNS, DNSSEC, and other modern DNS features. > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --Apple-Mail=_D5ED3C31-CCF5-4FC8-8963-BB4DA752AB30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Ben,

As a note, = Glenn and I worked on a revision of this today that I have sent out to = the list that should cover most of your comments.
Anything specifically naming "policy" = has been removed throughout the charter proposal. We did toss around the = idea of "resolver behavior" but ended up being a bit more general in = referring to information about the resolver, that can be used in = resolver selection. The main goal here is to provide a communication = mechanism in the IETF spec for properties that describe what a resolver = will serve, the most concrete example of which is information about = serving split DNS names. This communication mechanism could be used for = "policy" or "behavior" information, but that would certainly be out of = scope for this working group.

With regards to the text for "security = properties", this mainly came from boilerplate security charter text. I = don't read that as necessarily ruling out opportunistic use of = encryption as a strategy, but any communication of explicit information = between two parties (servers and clients in this example) should be = specified to be secure. I would argue that just trying DoH to a given = address does give you the security properties of HTTPS when you use = that; but that's also not any new protocol mechanism.

Best,
Tommy

On Jan = 14, 2020, at 1:43 PM, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:

Thanks for attempting a consensus charter, Glenn.  Some = comments inline.

On Thu, Jan 9, 2020 at = 5:56 PM Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> wrote:
...
> Proposed Working Group Charter
... =  
>
> Network operators that = start offering DNS encryption on their servers
> need a = way to indicate this support to clients. Beyond support for
> encrypted DNS, local networks may also have policy about = the use of DNS
> to non-local DNS servers. = Communicating such network policy to clients
> would = allow clients to make more informed decisions about which DNS
> servers to use.

I feel = strongly that we should avoid "policy" in the WG scope text.  We = appear to lack a shared understanding of what this word means, and it is = the focus of much conflict here.  Including it here seems like a = recipe for confrontation within the working group.  I also don't = think it's necessary for almost any of the goals mentioned on this list: = we can rephrase in a way that is both clearer and more broadly = acceptable.

In this = case, I would suggest: "... servers need a way to indicate this support = to clients.  Clients may also be able to make better decisions = about which DNS servers to use if they can learn more about the = resolution behaviors of each server.".

> The Adaptive DNS Discovery (ADD) working group will = define mechanisms and
> protocols to:
...
> - allow network providers to = communicate DNS policy to clients,
> including = information about locally-accessible names;

In this case, I would rephrase as "... = communicate information about resolver behavior to clients, including = ...".

...
> = Any mechanisms that specify interactions between clients and
> servers must provide the security properties expected of = IETF
> protocols, e.g., confidentiality protection, = integrity protection,
> and authentication with strong = work factor.

This appears to rule out opportunistic upgrade to DoH, as = well as the entire RESINFO framework adopted by DNSOP.  Personally, = I don't think "the security properties expected of IETF protocols" are = compatible with most of the use cases we've discussed, including the = ones mentioned in this charter text.  I think we would be better = off flipping this to explicitly focus on opportunistic protocols, and = promise to document appropriate guardrails against improper reliance on = security properties that are not provided.

While opportunistic security is not to = be relied on for crucial security properties, I think opportunistic = privacy (against a passive adversary) is valuable and worth = including in the working group's scope.  Also, opportunistic = upgrade would give clients a clear indication that they are speaking = directly to a modern resolver, allowing them to rely on modern DNS = features.  In the absence of such a signal, clients cannot rely on = any DNS features beyond basic A/AAAA queries, due to the lingering = deployment of buggy resolvers, forwarders, and middleboxes.  I know = that this has been a major factor in popular clients' decisions not = to make use of EDNS, DNSSEC, and other modern DNS features.
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

= --Apple-Mail=_D5ED3C31-CCF5-4FC8-8963-BB4DA752AB30-- From nobody Tue Jan 14 15:23:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D1D120889 for ; Tue, 14 Jan 2020 15:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 vV6mAQfcHcqo for ; Tue, 14 Jan 2020 15:23:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4983412006D for ; Tue, 14 Jan 2020 15:23:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A218ABE47; Tue, 14 Jan 2020 23:23:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tdqk0OjZevd; Tue, 14 Jan 2020 23:23:18 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2333BE3E; Tue, 14 Jan 2020 23:23:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579044198; bh=tzRgeba2Kw87JUjkZPzQfZ8jqIuWGYshphddHgiBAE0=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=BUn/jH6oiVnC3DpNK1Y1quK0GmpvsS24lQOVSbGXwQaD0fzbEk/BLJa2glcQjIXJe MZ79yNNhWCcIANUNeQHqAg4Zt9rbOJRRHJyhUDCAOGhkSRWOmDlGAMg6Nfr4c+ueW7 W77w2N2VYnxMzTkEp9QDccW7zIfcrFtWqAfbWUlI= To: Tommy Pauly , Ben Schwartz Cc: "Deen, Glenn (NBCUniversal)" , Alissa Cooper , Ted Lemon , ADD Mailing list , =?UTF-8?Q?Mirja_K=c3=bchlewind_=28IETF=29?= References: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> From: Stephen Farrell 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: <011e0d49-8299-e2b0-cd9e-fceda3a30c2a@cs.tcd.ie> Date: Tue, 14 Jan 2020 23:23:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="56naTb4H0blqqSjgjJStqipC4fjs3PdKX" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 14 Jan 2020 23:23:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --56naTb4H0blqqSjgjJStqipC4fjs3PdKX Content-Type: multipart/mixed; boundary="7XPE6uokGZqPM2jtAejcudvULLv2bK5xE"; protected-headers="v1" From: Stephen Farrell To: Tommy Pauly , Ben Schwartz Cc: "Deen, Glenn (NBCUniversal)" , Alissa Cooper , Ted Lemon , ADD Mailing list , =?UTF-8?Q?Mirja_K=c3=bchlewind_=28IETF=29?= Message-ID: <011e0d49-8299-e2b0-cd9e-fceda3a30c2a@cs.tcd.ie> Subject: Re: [Add] A proposed charter for ABCD References: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> In-Reply-To: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> --7XPE6uokGZqPM2jtAejcudvULLv2bK5xE Content-Type: multipart/mixed; boundary="------------FF785D908E5607CC750A2B0D" Content-Language: en-US This is a multi-part message in MIME format. --------------FF785D908E5607CC750A2B0D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/01/2020 22:45, Tommy Pauly wrote: >=20 > With regards to the text for "security properties", this mainly came > from boilerplate security charter text. Better deleted IMO. But clarity on whether or not opportunistic approaches are in scope is needed I reckon (as part of the charter). > I don't read that as > necessarily ruling out opportunistic use of encryption as a strategy, > but any communication of explicit information between two parties > (servers and clients in this example) should be specified to be > secure. I would argue that just trying DoH to a given address does > give you the security properties of HTTPS when you use that; but > that's also not any new protocol mechanism. FWIW, I don't agree with the above. I do think there's value in opportunistic approaches so long as there's some kind of credible longer term story as to how we get to better than opportunistic. I read your charter text as strongly discouraging that. In addition, if any step in the process lacks strong identification and authentication, then the overall is back to opportunistic. In particular, if the client does not start out already knowing a public key and a name for a resolver (or maybe just a public key if something "above" a resolver like a special purpose PKI were to exist) that the client "likes" then ISTM that HTTPS is no better than than opportunistic anyway. And since the status-quo ante is mostly DHCP, I think we'd be silly to ignore the potential for opportunistic improvement *if* we think there's a path from that to better eventually. (*) Cheers, S. (*) To try give an example of what I mean: if my laptop has successfully used resolver foo 1000 times in the last year without any hiccups, and I walk into a coffee shop that tells me via DHCP that I can use foo, then that's fine and dandy. That's not quite TOFU, maybe more like trust on thousandth use or TOTU perhaps? --------------FF785D908E5607CC750A2B0D 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----- --------------FF785D908E5607CC750A2B0D-- --7XPE6uokGZqPM2jtAejcudvULLv2bK5xE-- --56naTb4H0blqqSjgjJStqipC4fjs3PdKX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4eTWMACgkQWrL68XsX K+p/VQ/9HscSBZANsTYih7tm3ZUTqa/5S50RCG6gRspPaH1e5q/BFYJcV20T9KZ8 jwDGCS/FTrjfp+0BdkG9hnl8rFXmGY4I4vviknGiciy3/2FU6FpzZeR7Ko+JtMto KUHzg5+y7YqaE1p6HaLrRHgbJXfipaOkZ6LZtPgE8tt7mJGZgKA/XXfLJY7uKViR rqJkYHzzBf5+Jll4sCj0AZVzdZu1gRnBfwYY++rUaMueD8baBCz7LmoQymjeWElS m/x/9YLCmX7Eiw5HHfqYUjmtsooeTz8MXyTT0J/BIxLOTtxK1pMEsO3eMZBeBKtl der+bxnZb0+RdklsOSVRpKIWXsHJ8w85yy4bt9A1Ta1kxCn5607n9ELtOAOhMTFi gM2USU2DTcK/9dUSKz5jvigNIxs/ymJ+sIEBKkpTnYkpUSxVMoEpHJDyHTbCf/On vnvxMiBeTbx2ud+dSiZ++XHuiyBmKuL/LNanWKYPe35onTe0/8/UtBEALEAjB4RJ JUpYpIguKOYQQroCPA2FAYDPhmDqS5lKH0GgbihnVZZ1IW0TOsSlQfpqohgKjkUb VN0BA6b1hxCxu/hP1yR58QmWYkL9h6BpGXk0u3VfXPVrmpuer2U05Bf0dT4Bdp0A TjFGWc48RkzXnnpaTBpT35jYk3X0Bgg6RzTMTQZNZiQ4oEO7JU0= =GsHL -----END PGP SIGNATURE----- --56naTb4H0blqqSjgjJStqipC4fjs3PdKX-- From nobody Tue Jan 14 16:45:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2F12002F for ; Tue, 14 Jan 2020 16:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 yOKJ4LJfqJra for ; Tue, 14 Jan 2020 16:45:23 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 3228C12006D for ; Tue, 14 Jan 2020 16:45:23 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id x18so9482512vsq.4 for ; Tue, 14 Jan 2020 16:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A6I+2EBScw5t7cHZCRM5rocgnndt0+cZpC7IcuaqTmU=; b=eI1e/A35s0W5UQdgxgznXmJpR/t5rSnU/ab9sqxmg+aM8RUMG5MHKb2T1Y1mbUFoO+ Pwv8S4cFdmCBCoyu3ILKTrgXyZcVLB4UWoEBXZOMfcAIqE5OYrDQIcOgFpa517luibum NgBmXGg0Ikbg2t5Uw6IEgyflni6MSQ2mWMNxM5XB6L1MqAY8eXYqpIydYpRDQYRxmAiH LsShJbtDd8F+5FHokW5nXTj0cATZI59TiaY3ZjYBiBU6NlU4VdzG3GUMbaR+Ga2m24H2 GFkOJ+Q5dYwTU0bSwv81zjpM/mryTGECoUqkDHqzAlSnLoXobYdzO0UMlKeDsIDHcMl0 K3qA== 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=A6I+2EBScw5t7cHZCRM5rocgnndt0+cZpC7IcuaqTmU=; b=Ayb9CQ3rIwgsBuhP6XtjOjZfu+KpEIt+BE9FpcqhFZVYd27mdbMLYQrE9c8RHtlMip 1B1oma8Bh6cqUlcqpCbOxccxWPwc58EQXExIH8R9O6qS/QGQvwNUsS4gbI5kHDHhvG8w O5/exVNWYsitsLEVasOOL5jUymlr69Q8lZDKGN6XB0ktd3sfSqLOk6uMhoDR0Qi0qLD4 01Ek6uuvPP3BYYvYndH+nhmSQqxdlxwjzop1S/OoDRQimZicRKGM9O9DprIPBHolUjP2 5iBWUUD4cdlFK9pHHCNjTRGgz+0VjbO7MvMXuW+G4Y9QaOwrgcBBRGrA5EqEWny7rsa2 aAoQ== X-Gm-Message-State: APjAAAUAQWwTN7/p2clqonqJOOQf2LkbqiRkQjAfBKdmd4kYw2KWNl1z 8C4dYhjhs0btyEyn0gx88J4W7EZvH6WJuVP+9F7oGg== X-Google-Smtp-Source: APXvYqwyLUgLuEyYoHNgNXE2tulbPHkPkFg1RBmOzgQ8R2dCUzG7KPKQ29fFzGaf03WbBULNJFJvhqPRHtJ+ojuMR5c= X-Received: by 2002:a67:fc09:: with SMTP id o9mr2948598vsq.75.1579049122104; Tue, 14 Jan 2020 16:45:22 -0800 (PST) MIME-Version: 1.0 References: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> <011e0d49-8299-e2b0-cd9e-fceda3a30c2a@cs.tcd.ie> In-Reply-To: <011e0d49-8299-e2b0-cd9e-fceda3a30c2a@cs.tcd.ie> From: Brian Dickson Date: Tue, 14 Jan 2020 16:45:10 -0800 Message-ID: To: Stephen Farrell Cc: Tommy Pauly , Ben Schwartz , Ted Lemon , ADD Mailing list , Alissa Cooper , =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= , "Deen, Glenn (NBCUniversal)" Content-Type: multipart/alternative; boundary="0000000000000188ed059c23060b" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 00:45:29 -0000 --0000000000000188ed059c23060b Content-Type: text/plain; charset="UTF-8" On Tue, Jan 14, 2020 at 3:23 PM Stephen Farrell wrote: > > Hiya, > > On 14/01/2020 22:45, Tommy Pauly wrote: > > > > With regards to the text for "security properties", this mainly came > > from boilerplate security charter text. > > Better deleted IMO. But clarity on whether or not > opportunistic approaches are in scope is needed I > reckon (as part of the charter). > > > I don't read that as > > necessarily ruling out opportunistic use of encryption as a strategy, > > but any communication of explicit information between two parties > > (servers and clients in this example) should be specified to be > > secure. I would argue that just trying DoH to a given address does > > give you the security properties of HTTPS when you use that; but > > that's also not any new protocol mechanism. > > FWIW, I don't agree with the above. > > I do think there's value in opportunistic approaches so > long as there's some kind of credible longer term story > as to how we get to better than opportunistic. I read > your charter text as strongly discouraging that. > > In addition, if any step in the process lacks strong > identification and authentication, then the overall is > back to opportunistic. In particular, if the client > does not start out already knowing a public key and a > name for a resolver (or maybe just a public key if > something "above" a resolver like a special purpose > PKI were to exist) that the client "likes" then ISTM > that HTTPS is no better than than opportunistic > anyway. > > And since the status-quo ante is mostly DHCP, I think > we'd be silly to ignore the potential for opportunistic > improvement *if* we think there's a path from that to > better eventually. (*) > > Cheers, > S. > > (*) To try give an example of what I mean: if my laptop > has successfully used resolver foo 1000 times in the last > year without any hiccups, and I walk into a coffee shop > that tells me via DHCP that I can use foo, then that's > fine and dandy. That's not quite TOFU, maybe more like > trust on thousandth use or TOTU perhaps? > > I think we are likely converging on some common, good ideas. There was a reference to work in the INT area, on PvD, which I think can dovetail with the things we're thinking of here. (PvD is basically "provisioning domains", which by my reading really means "domains within which provisioning occurs" rather than "provisioning DNS".) Here's how I think the two could interact in a way that gets us where we want to be: - The PvD is a "context" within which any bootstrapping or recall occurs, for going from supplied thing (e.g. DHCP address) to identified, authenticated, trusted resolver over a privacy-preserving channel. - If a given PvD context is new, TOFU via a well-known name, which asserts its own trust anchor over a signed zone (of the well-known name). - The signed zone contains a reference to a unique name (globally unique, but locally scoped, i.e. works without requiring any global DNS delegation, works in non-unique private address space, works without PKI) - The signed zone also has a trust anchor (DNSKEY) for the unique name, so all other information can be obtained from the signed zone under that unique name. - If a given PvD context is not new, the trust anchor for the well-known name has been saved - If the well-known name points at the previously used unique name, the only reason the trust anchor of the unique name might have changed is if the key was rolled, which is a valid possibility. Use the copy under the well-known name if the trust anchor has changed. - If the trust anchor hasn't changed, it is moot as to which identical copy is used (from well-known name or from unique name) - If the trust anchor for the well-known name doesn't match, reject it, ignore the well-known name entirely, and jump to the previously bootstrapped secure unique name (using the stored trust anchor of the unique name). It still starts with TOFU, but only if the client doesn't have anything better configured, and only if it is the first time it has encountered this environment. If the name of the resolver is resolvable from the global public DNS context (has a real name of its own), there is no need to rely on anything other than the name learned via the TOFU step. The DNSSEC elements can chain from the root trust anchor. If the name of the resolver is not resolvable from the global public DNS, that means that PKI won't work, so certificates need to be issued and validated via some other means (necessarily), which suggests DANE TLSA record(s) learned in the securely bootstrapped uniquely named resolver's own zone. Something better than TOFU can be worked out in the longer term, but that doesn't need to be (IMHO) done within DNS WGs, so long as the data given to clients is compatible with the secure bootstrap process (e.g. DNSSEC trust anchor, and possibly the resolver name.) Brian --0000000000000188ed059c23060b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 14, 2020 at 3:23 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 14/01/2020 22:45, Tommy Pauly wrote:
>
> With regards to the text for "security properties", this mai= nly came
> from boilerplate security charter text.

Better deleted IMO. But clarity on whether or not
opportunistic approaches are in scope is needed I
reckon (as part of the charter).

> I don't read that as
> necessarily ruling out opportunistic use of encryption as a strategy,<= br> > but any communication of explicit information between two parties
> (servers and clients in this example) should be specified to be
> secure. I would argue that just trying DoH to a given address does
> give you the security properties of HTTPS when you use that; but
> that's also not any new protocol mechanism.

FWIW, I don't agree with the above.

I do think there's value in opportunistic approaches so
long as there's some kind of credible longer term story
as to how we get to better than opportunistic. I read
your charter text as strongly discouraging that.

In addition, if any step in the process lacks strong
identification and authentication, then the overall is
back to opportunistic. In particular, if the client
does not start out already knowing a public key and a
name for a resolver (or maybe just a public key if
something "above" a resolver like a special purpose
PKI were to exist) that the client "likes" then ISTM
that HTTPS is no better than than opportunistic
anyway.

And since the status-quo ante is mostly DHCP, I think
we'd be silly to ignore the potential for opportunistic
improvement *if* we think there's a path from that to
better eventually. (*)

Cheers,
S.

(*) To try give an example of what I mean: if my laptop
has successfully used resolver foo 1000 times in the last
year without any hiccups, and I walk into a coffee shop
that tells me via DHCP that I can use foo, then that's
fine and dandy. That's not quite TOFU, maybe more like
trust on thousandth use or TOTU perhaps?


I think we are likely converging on so= me common, good ideas.

There was a reference to wo= rk in the INT area, on PvD, which I think can dovetail with the things we&#= 39;re thinking of here.
(PvD is basically "provisioning doma= ins", which by my reading really means "domains within which prov= isioning occurs" rather than "provisioning DNS".)
=
Here's how I think the two could interact in a way that = gets us where we want to be:
- The PvD is a "context" w= ithin which any bootstrapping or recall occurs, for going from supplied thi= ng (e.g. DHCP address) to identified, authenticated, trusted resolver over = a privacy-preserving channel.
- If a given PvD context is new, TO= FU via a well-known name, which asserts its own trust anchor over a signed = zone (of the well-known name).
- The signed zone contains a refer= ence to a unique name (globally unique, but locally scoped, i.e. works with= out requiring any global DNS delegation, works in non-unique private addres= s space, works without PKI)
- The signed zone also has a trust an= chor (DNSKEY) for the unique name, so all other information can be obtained= from the signed zone under that unique name.
- If a given PvD co= ntext is not new, the trust anchor for the well-known name has been saved
- If the well-known name points at the previously used unique name= , the only reason the trust anchor of the unique name might have changed is= if the key was rolled, which is a valid possibility. Use the copy under th= e well-known name if the trust anchor has changed.
- If the trust= anchor hasn't changed, it is moot as to which identical copy is used (= from well-known name or from unique name)
- If the trust anchor f= or the well-known name doesn't match, reject it, ignore the well-known = name entirely, and jump to the previously bootstrapped secure unique name (= using the stored trust anchor of the unique name).

It still starts with TOFU, but only if the client doesn't have anythin= g better configured, and only if it is the first time it has encountered th= is environment.

If the name of the resolver is res= olvable from the global public DNS context (has a real name of its own), th= ere is no need to rely on anything other than the name learned via the TOFU= step. The DNSSEC elements can chain from the root trust anchor.
=
If the name of the resolver is not resolvable from the globa= l public DNS, that means that PKI won't work, so certificates need to b= e issued and validated via some other means (necessarily), which suggests D= ANE TLSA record(s) learned in the securely bootstrapped uniquely named reso= lver's own zone.

Something better than TOFU ca= n be worked out in the longer term, but that doesn't need to be (IMHO) = done within DNS WGs, so long as the data given to clients is compatible wit= h the secure bootstrap process (e.g. DNSSEC trust anchor, and possibly the = resolver name.)

Brian=C2=A0
--0000000000000188ed059c23060b-- From nobody Tue Jan 14 16:56:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C95B120058 for ; Tue, 14 Jan 2020 16:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 v4fvUYYFlVX7 for ; Tue, 14 Jan 2020 16:56:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D566F12002F for ; Tue, 14 Jan 2020 16:56:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C281ABE24; Wed, 15 Jan 2020 00:56:01 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0Zm8Dtz9JHi; Wed, 15 Jan 2020 00:56:00 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 38AA8BE20; Wed, 15 Jan 2020 00:56:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579049760; bh=JH61VTiHVUdQJ8MZJbXpR2hgQz2SKAH9sgsFzDdQd0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eGW/fxF57AqVEnh7slu7u8kwSJ/+/wPqIgqhSosWhQIHdquFYmHWCm9LnN/mNCCOq r7kUtpTrwQfiDDYfH7imr/nj3WTFmD4vXcOE+ctsFiwAQxDGhDnYPtmFwec6SOugnY 4S/Wyck8GkMKyYMKKpPpQ5WSnhd/TD27bgPneO9w= To: Brian Dickson Cc: "Deen, Glenn (NBCUniversal)" , Alissa Cooper , Ted Lemon , Ben Schwartz , ADD Mailing list , =?UTF-8?Q?Mirja_K=c3=bchlewind_=28IETF=29?= , Tommy Pauly References: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> <011e0d49-8299-e2b0-cd9e-fceda3a30c2a@cs.tcd.ie> From: Stephen Farrell 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, 15 Jan 2020 00:55:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2CigaG2MfVG23LA93Kp0ac8D5hTloFvNk" Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 00:56:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2CigaG2MfVG23LA93Kp0ac8D5hTloFvNk Content-Type: multipart/mixed; boundary="eO87QIG9OetP56Z7Z2ENjnRVfKBddcjyb"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson Cc: "Deen, Glenn (NBCUniversal)" , Alissa Cooper , Ted Lemon , Ben Schwartz , ADD Mailing list , =?UTF-8?Q?Mirja_K=c3=bchlewind_=28IETF=29?= , Tommy Pauly Message-ID: Subject: Re: [Add] A proposed charter for ABCD References: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> <011e0d49-8299-e2b0-cd9e-fceda3a30c2a@cs.tcd.ie> In-Reply-To: --eO87QIG9OetP56Z7Z2ENjnRVfKBddcjyb Content-Type: multipart/mixed; boundary="------------418FEEE3C6B6657B8CA9CC64" Content-Language: en-US This is a multi-part message in MIME format. --------------418FEEE3C6B6657B8CA9CC64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/01/2020 00:45, Brian Dickson wrote: > - If a given PvD context is not new, the trust anchor for the well-know= n > name has been saved "Not new" could be satisfied by dropping WiFi and then starting over in milliseconds. I'm not clear that that'd be ok here. So it may or may not be the case that we're converging. A WG that is chartered to analyse opportunistic situations could figure that out I guess. S. --------------418FEEE3C6B6657B8CA9CC64 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----- --------------418FEEE3C6B6657B8CA9CC64-- --eO87QIG9OetP56Z7Z2ENjnRVfKBddcjyb-- --2CigaG2MfVG23LA93Kp0ac8D5hTloFvNk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4eYx8ACgkQWrL68XsX K+oMlA/+IafohC5y3dTghw9tC588fiT3vt/cJ7TBePb7mDYVWmSO54CbRdlRGUrm GFH4l3/M+SHOyiexNmUIAZPSj6mXJ866TaFTmcSIxkdq/ZVxhVGoAekWJxmEmwP3 ZbNTWXmeFIVedMvuSPwxihE9zn+sYhHIYnHxJr7jfVWfHVYgdmB3JTwjzumEE389 brR4DpX1aaUO1/FrEiG8164Pcn4VSgMG2dNjCwk5eQU4TNjrfr/a/nQM5lAjBDnM BQ96eamqbgcAWl6+6gMVeVqWay5bEu8B9EtvZJLG96TkzpCVcwn+Sns2wkw+cT+/ y5OQwV5B5lgDkeRE9wxatdU9KovgD+QbvjdxjWiovdOTGJAShIMX3GOqP5cZ8EpG fkkqfO3hE3DQtv2sw6Q6d9MO8U+cU/j6g08gAwNxlEo+EZjbj8pIrIm6H2f71qZW cO37rerdHzWxOdVvaS2Yj9D7rxX7c36NvQoC6PhyxTPN42OjTgBdesR3VZW+YzoA i8ml1BxjBMTu5PggIYdSCzC8a5fY0lGWMm5UyrlQsJZZg4dv/j2NhRAvqu6i6e5e X2Ec0W+HunUPRYZpbSnN3nbr4GwIDzjV4QTJcs95ffv0NEep6SrM/dcY7uFqdO+5 /5+7N3vMjVfRO5FyR2v9CakUtj3kmHEpYAJ2mQCqiTTAjS33ugc= =wOS7 -----END PGP SIGNATURE----- --2CigaG2MfVG23LA93Kp0ac8D5hTloFvNk-- From nobody Tue Jan 14 17:27:07 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1362E12006D for ; Tue, 14 Jan 2020 17:27:06 -0800 (PST) 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, 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 IJb9iuAD9Bsc for ; Tue, 14 Jan 2020 17:27:04 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 4FF5A120041 for ; Tue, 14 Jan 2020 17:27:04 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id dp13so6653744qvb.7 for ; Tue, 14 Jan 2020 17:27:04 -0800 (PST) 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=OaAKaF4cj5UwuI4cifFk/VDPXi+CGfh8L34KCWunHRQ=; b=uLEuv7R2xEis4ZQrNXh839DLe2KNDBUgxHMdmOrRs6s+N09zxQru6hB6l52C9YZITr FFT63tIeqnDBC22a5pbPetelMrkOB+n8nnuitKuf9lxiq1n9+I4S33k4YhR3X2kM/nIb z8V3xEOaa6HRbXlLeagpQQO2Ids0WMV8wkHqTA0xWN6r/qFT13P5Iwne+9jJXZ6tZZzF 2xfDA/8f40KbKNfGW5SyOBi3Gzls+wFGSbAjk9R2159XP8JDaH1//Bd68njsrsep4R26 tNNw3YXDoa+cMRKsI8fPWqhKN5BTKcS09bb62hk7gP9WJNyg0Lpfx1ItBS3UQnSoS91S ikyw== 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=OaAKaF4cj5UwuI4cifFk/VDPXi+CGfh8L34KCWunHRQ=; b=P6PQCW+MGAVuf60fkxsEuHOghFiE2CdfC+ZM1yUuy4QLiHRfH3W3aS277iqrdxhbm7 gSurklx7JPo++pxpRb6Sf/TJDabDBMLVGpkBYRNRhXZUX+0MeexTZFE+5iUpMXZwzsxj /Vk5KLOmW38BbcMBgRYHkIsW6IfNqWW7EO2XaC+k5TdJjoThoM2a7BG9bvvZoy+ZozWo HHxlmc3Mxf1oJvuTae7+sVIaWINWd67fcUy1zoYC9zLa0z1yrg4WX4X9fdhGe0xyKRFe ZVehF0Cuv+3K9XXngYkrnWZMN9BMjp0bIhwKlwXVyjRl6lu9dT6OaRLMgcGcljQQy4wi ekcg== X-Gm-Message-State: APjAAAV7Jmbj1CKVKkpaljKh+9sgmPyaIGWo7UxZAWAdO3Z96OSkpyFY 7oYlEElLi4MalAFLuGXlEsOInw== X-Google-Smtp-Source: APXvYqzNLp/PXb52ffnDJeZ9DoRR0S+2rOnMvestN0a7svnu1X/tPsXsYPZyG+NkN6pQKxSUe625SQ== X-Received: by 2002:a05:6214:13ef:: with SMTP id ch15mr20036634qvb.183.1579051623495; Tue, 14 Jan 2020 17:27:03 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:add0:b2b5:e34f:2444? ([2601:18b:300:36ee:add0:b2b5:e34f:2444]) by smtp.gmail.com with ESMTPSA id i19sm7455812qki.124.2020.01.14.17.27.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jan 2020 17:27:03 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9CF1E689-26CB-46BA-8C8B-B19C5B30E44C Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 14 Jan 2020 20:27:02 -0500 Message-Id: References: Cc: Stephen Farrell , Tommy Pauly , Ben Schwartz , ADD Mailing list , Alissa Cooper , =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= , "Deen, Glenn (NBCUniversal)" In-Reply-To: To: Brian Dickson X-Mailer: iPad Mail (17E177) Archived-At: Subject: Re: [Add] A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 01:27:06 -0000 --Apple-Mail-9CF1E689-26CB-46BA-8C8B-B19C5B30E44C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Jan 14, 2020, at 7:45 PM, Brian Dickson w= rote: >=20 > PvD is basically "provisioning domains", which by my reading really means "= domains within which provisioning occurs" rather than "provisioning DNS". No need to speculate=E2=80=94the term is defined in RFC 7556=E2=80=94Multipl= e Provisioning Domain Architecture. https://tools.ietf.org/html/rfc7556 --Apple-Mail-9CF1E689-26CB-46BA-8C8B-B19C5B30E44C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Jan 14, 2020, at 7:45 PM, Brian Dickson &= lt;brian.peter.dickson@gmail.com> wrote:
PvD is basically "provisioning domains", which by my reading reall= y means "domains within which provisioning occurs" rather than "provisioning= DNS".

No need to speculate=E2=80=94the term is d= efined in RFC 7556=E2=80=94Multiple Provisioning Domain Architecture.
<= div>


= --Apple-Mail-9CF1E689-26CB-46BA-8C8B-B19C5B30E44C-- From nobody Wed Jan 15 03:13:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5931200B6 for ; Wed, 15 Jan 2020 03:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 XebaBIo5vj2L for ; Wed, 15 Jan 2020 03:12:57 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E75C1200B8 for ; Wed, 15 Jan 2020 03:12:57 -0800 (PST) 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 5B1DA6A26A for ; Wed, 15 Jan 2020 12:12:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1579086775; bh=9e+dbHFhoGiVkJPthli/eJHf5wxXsdldVQiM51Hd8p8=; h=From:Subject:Date:References:To:In-Reply-To:From; b=H6OwN/U1iaQUj7ZWrdM3kwGffHeag9k3md1LfQYXfDPdlFZosG/9icfn7/Hodn/7B Hx3WtISr2V0ZDfICoaSj1zdVctUVFEjfvWJksmoVEPSqzpWZuVBxzKnXpkD4/Uw5Wr +i6xEhXih4ylIsEmt9wi0AD/pcmdO41iDY1SoJ5tkU8olkTgNox4n4Q/t9vlXgh3lF NklJm8SnMHyclc+/Lk1Hx2JCTTLsZL+TrNjoCG5XbKNw9B2jHj2b/9w5yk6ZFIk4gV oFKnC//dR3NnDXGN6mjeZBiVFKRdsdXLiegGXMf+m5p5wPNNfo6qOBX4YpYRuCmuH7 iJaLlKBZ2ax+g== Received: from [192.168.1.170] (host109-158-192-48.range109-158.btcentralplus.com [109.158.192.48]) (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 28EC53C01A3 for ; Wed, 15 Jan 2020 12:12:55 +0100 (CET) From: Neil Cook Content-Type: multipart/alternative; boundary="Apple-Mail=_CF6B61BD-5081-4E1D-8127-BF370951CF42" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 15 Jan 2020 11:12:53 +0000 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> To: ADD Mailing list In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Message-Id: X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 11:13:02 -0000 --Apple-Mail=_CF6B61BD-5081-4E1D-8127-BF370951CF42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support this proposed charter with the exception of the following = language: > Any mechanisms that specify interactions between clients and > servers must provide the security properties expected of IETF > protocols, e.g., confidentiality protection, integrity protection, > and authentication with strong work factor. I agree with Stephen Farrell's comments on the other thread on this = topic, namely: > On 14 Jan 2020, at 23:23, Stephen Farrell = wrote: > I do think there's value in opportunistic approaches so > long as there's some kind of credible longer term story > as to how we get to better than opportunistic. I read > your charter text as strongly discouraging that. Neil > On 14 Jan 2020, at 22:38, Tommy Pauly = wrote: >=20 > Hi all, >=20 > I wanted to share an updated proposal for an ADD charter, based on the = feedback and discussion on the list in the past several weeks. >=20 > This is based on the original proposal that was sent in December, = taking into account various comments and suggestions. Glenn Deen, Andrew = Campling, and I worked on this revision together and came to consensus = on its contents. >=20 > Thoughts and comments are welcome as always! >=20 > (Note that the proposed name of the group was not changed, and is = entirely open to bikeshedding. Naming is hard!) >=20 > Best, > Tommy >=20 >=20 >=20 > Adaptive DNS Discovery (ADD) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Proposed Working Group Charter >=20 > Sending DNS messages over encrypted transports, as defined in DNS over > TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides > benefits to the security and privacy of DNS data. Clients, such as > applications and host operating systems, have started adopting these > protocols to provide these user benefits. >=20 > This working group will focus on discovery and selection of DNS = resolvers > by DNS clients in a variety of networking environments, including = public > networks, private networks, and VPNs; supporting both encrypted and > unencrypted resolvers. >=20 > Clients adopting encrypted DNS protocols need to determine which DNS > servers support encrypted transports, and which server to use for = specific > queries if multiple servers are available. These decisions can vary = based > on the network environment, and also based on the content and purpose = of > the client queries. >=20 > Network operators that start offering DNS encryption on their servers = also > need a way to indicate this support to clients. Communicating = information > about resolver configuration and behavior allows clients to make more > informed decisions about which DNS servers to use. For example, a = resolver > may be able to resolve private or local names as a split DNS server. >=20 > The Adaptive DNS Discovery (ADD) working group will work on the = following > deliverables: >=20 > - define a mechanism that allows clients to discover DNS resolvers, > including encrypted DNS servers, that are available to the client > either on the public Internet or on private or local networks; >=20 > - define a mechanism that allows communication of DNS resolver > information to clients for use in selection decisions; >=20 > - develop an informational document that describes how client > applications and systems can manage selection of DNS resolvers > in various network environments and use cases. >=20 > Any mechanisms that specify interactions between clients and > servers must provide the security properties expected of IETF > protocols, e.g., confidentiality protection, integrity protection, > and authentication with strong work factor. >=20 > This working group will coordinate with dnsop, doh, and dprive for any > changes required in DNS protocols. It will also work with capport to > ensure that solutions are applicable to captive networks. >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add Neil Cook neil.cook@open-xchange.com = --------------------------------------------------------------------------= ----------- Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court = Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael = Knapstein, Stephan Martin=20 Chairman of the Board: Richard Seibt European Office:=20 Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District = Court Siegen, HRB 8718=20 Managing Director: Frank Hoberg US Office:=20 Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA=20 = --------------------------------------------------------------------------= ----------- --Apple-Mail=_CF6B61BD-5081-4E1D-8127-BF370951CF42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = support this proposed charter with the exception of the following = language:

Any mechanisms that specify interactions = between clients and
servers must provide the security = properties expected of IETF
protocols, e.g., = confidentiality protection, integrity protection,
and = authentication with strong work factor.

I agree with Stephen Farrell's comments = on the other thread on this topic, namely:

On = 14 Jan 2020, at 23:23, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> I do think there's value in opportunistic =
approaches so
> long as there's some kind of credible longer term story
> as to how we get to better than opportunistic. I read
> your charter text as strongly discouraging that.
Neil

On 14 Jan 2020, at 22:38, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Hi = all,

I wanted to share an updated proposal = for an ADD charter, based on the feedback and discussion on the list in = the past several weeks.

This is based on = the original proposal that was sent in December, taking into account = various comments and suggestions. Glenn Deen, Andrew Campling, and I = worked on this revision together and came to consensus on its = contents.

Thoughts and comments are welcome = as always!

(Note that the proposed name of = the group was not changed, and is entirely open to bikeshedding. Naming = is hard!)

Best,
Tommy



Adaptive DNS = Discovery (ADD)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Proposed Working Group Charter

Sending DNS messages over encrypted transports, as defined in = DNS over
TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) = [RFC 8484], provides
benefits to the security and privacy = of DNS data. Clients, such as
applications and host = operating systems, have started adopting these
protocols = to provide these user benefits.

This = working group will focus on discovery and selection of DNS resolvers
by DNS clients in a variety of networking environments, = including public
networks, private networks, and VPNs; = supporting both encrypted and
unencrypted resolvers.

Clients adopting encrypted DNS protocols need = to determine which DNS
servers support encrypted = transports, and which server to use for specific
queries = if multiple servers are available. These decisions can vary based
on the network environment, and also based on the content and = purpose of
the client queries.

Network operators that start offering DNS encryption on their = servers also
need a way to indicate this support to = clients. Communicating information
about resolver = configuration and behavior allows clients to make more
informed decisions about which DNS servers to use. For = example, a resolver
may be able to resolve private or = local names as a split DNS server.

The = Adaptive DNS Discovery (ADD) working group will work on the following
deliverables:

- define a = mechanism that allows clients to discover DNS resolvers,
including encrypted DNS servers, that are available to the = client
either on the public Internet or on private or = local networks;

- define a mechanism that = allows communication of DNS resolver
information to = clients for use in selection decisions;

- = develop an informational document that describes how client
applications and systems can manage selection of DNS = resolvers
in various network environments and use = cases.

Any mechanisms that specify = interactions between clients and
servers must provide the = security properties expected of IETF
protocols, e.g., = confidentiality protection, integrity protection,
and = authentication with strong work factor.

This = working group will coordinate with dnsop, doh, and dprive for any
changes required in DNS protocols. It will also work with = capport to
ensure that solutions are applicable to captive = networks.

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


Neil Cook
neil.cook@open-xchange.com

---------------------------------------------------------------= ----------------------
Open-Xchange AG, Rollnerstr. 14, = 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, = Michael Knapstein, Stephan Martin 
Chairman of = the Board: Richard Seibt

European = Office: 
Open-Xchange GmbH, Olper Huette = 5f, D-57462 Olpe, Germany, District Court Siegen, HRB = 8718 
Managing Director: Frank Hoberg
US Office: 
Open-Xchange. Inc., 530 = Lytton Avenue, Palo Alto, CA 94301, USA 
---------------------------------------------------------------= ----------------------

= --Apple-Mail=_CF6B61BD-5081-4E1D-8127-BF370951CF42-- From nobody Wed Jan 15 05:07:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2708E120106 for ; Wed, 15 Jan 2020 05:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infoblox.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBDXfI8kivMR for ; Wed, 15 Jan 2020 05:07:26 -0800 (PST) Received: from mx0b-00333e01.pphosted.com (mx0b-00333e01.pphosted.com [148.163.141.155]) (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 CB31A1201DB for ; Wed, 15 Jan 2020 05:07:26 -0800 (PST) Received: from pps.filterd (m0158919.ppops.net [127.0.0.1]) by mx0b-00333e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00FD46AM003649; Wed, 15 Jan 2020 05:07:24 -0800 Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) by mx0b-00333e01.pphosted.com with ESMTP id 2xfes6wny4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Jan 2020 05:07:24 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AOHVbFTfNYbnNsf4MWklsbsFb/M9Qj3sBgeTWIuu7XfQC6i2CJb2RYAKLD5iuECCSrwClDpIq0jBMpAhBcbKNc5VREPmckgfczxCqvw97U06XHzCnhgIjHTb5PbgP9bNXvJs9bcvKugaCgXJYaFuRncYKXCVj+6DwxGHyT23mgLsHup7huJ+MaxeKOHbLefZfnH6T5oG0FKm21KEP70ah39kSXnW/BeUylxqoXRKhnTDbfssaVAjE15tzxpE3TvxfQP/ZNQ/byYRpbJE62Kr+P1w24+TiDjmO7HaYoBBoshLz3Hh1bEmOf+7T49M+crsroFbEfrsgZoEWVNxRf/jNw== 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=b5m/LrfI5HP1qw+tJA5o2vA2C7j8TMm3p5H5izhbg3A=; b=KpMEBMG2oHBTkBz6GYXyHe2vTAog8QFB4iLmcdv3vXIZuZQMfx3Gst0d7n47ypBMviJXnKONuwVwNG2wt3CrQNoOWTwQ5EKF6IEdN/64L+ihpxZOBp13Zvl1iFabWCxPvqB0EQNCj5IjHQ2pwswt/2SzhgyHvi9X58SgB+58GNBkT845aLuysuTg7SVtt0PONn3n4hwMpuSFI2M33JS+mzAk71SfS+Z/GWE72YMHY3d/Aet0KUwXv1FP+PzE8L92KtHdUcjjCLIM2wB1ikIbE2JuwelD8umO6OG92AWCPbM6L8IJDQ2NkYW29OPyv5FcgKl0mYhU9CjVz7bFG3hm8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=infoblox.com; dmarc=pass action=none header.from=infoblox.com; dkim=pass header.d=infoblox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infoblox.onmicrosoft.com; s=selector2-infoblox-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b5m/LrfI5HP1qw+tJA5o2vA2C7j8TMm3p5H5izhbg3A=; b=dUFn5wshqEgZ/UsbgJd/eo+UD36XWQCORPC1MDCJEuok7HuC4+uD1Hv6JB++kFMCL2laJM0ufTb2WQCfSfv9g/jsNPzBhIxDkY0Sv+BYBm+Xdz3d7wLi9RelPanahGwTpm22p740eDbSxtCTebVnYADBSnJYhlJD+9B4FYDEibc= Received: from DM5PR07MB2874.namprd07.prod.outlook.com (10.168.102.12) by DM5PR07MB3147.namprd07.prod.outlook.com (10.172.90.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Wed, 15 Jan 2020 13:07:22 +0000 Received: from DM5PR07MB2874.namprd07.prod.outlook.com ([fe80::b82f:7e3f:ff1e:1bf2]) by DM5PR07MB2874.namprd07.prod.outlook.com ([fe80::b82f:7e3f:ff1e:1bf2%11]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 13:07:22 +0000 From: Paul Adair To: Tommy Pauly , ADD Mailing list Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVyytcVMvsUgMaukyu7l6H2129uafrToWA Date: Wed, 15 Jan 2020 13:07:21 +0000 Message-ID: <0E6BAB56-3B54-4032-BD17-30770F242BB1@infoblox.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 x-originating-ip: [2600:1700:570:964f:b5a2:429e:8950:2e61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee0d9701-f34b-442c-272d-08d799bbdbb6 x-ms-traffictypediagnostic: DM5PR07MB3147: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39850400004)(346002)(396003)(189003)(199004)(6506007)(316002)(8936002)(2616005)(66574012)(110136005)(478600001)(15650500001)(86362001)(5660300002)(71200400001)(8676002)(966005)(186003)(6512007)(81156014)(81166006)(6486002)(36756003)(66556008)(66476007)(66446008)(66946007)(76116006)(64756008)(2906002)(91956017)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR07MB3147; H:DM5PR07MB2874.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: infoblox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /ZsC/E26y4g6DmlBE+DYZe7Pi813sSqlV6QrFmQG80561JWPULIKUQ4e0TKd8cN1pleXYSztVYjwkflkJCyGPO0Tmkr+/6SrbfJERYbjFR7tT4LhOh5gjNBDw++yHLXlVE5PnYxikpt/jTeYi7miAzQSitjLwwAVRHPhXcS8saVvr+OuF0Ft6Q3osguHGjeWcOuJ0X8NNyYOOkykZ9BK03fLk/rB41zc3j1QbfEW7aBK48z2vK/3+pQBtLPVsXq3LZNmhszv8jQOtEJ2VxRQdS5aWy1jCEsS/jdcGA90cSr8y2h0ykW3TnrMgm84IauXL4tGRPHEw8P04pjN8udreK3934Bk/SAb4EWJ3oP3IvlQ8Dir+Xkel8gFaxixmmiB40uQ8ebGc7yIEDQbbjix3Yl9/KR8doOPQwfPGuPLuMa+OnTPdmuyNVamBGSW7CRFMBznpStw0O/jtHhFHEwT2/DbX+VxNeQQsLollThib4o= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0CA896A941D7E240ABDA924AF07F0C23@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: infoblox.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee0d9701-f34b-442c-272d-08d799bbdbb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 13:07:21.7677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ccf6dc4a-9fe9-4c20-85a6-46d2709e8435 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N1GsC7vjeFtv7NJ/56VfbBImm/GI40zHWvOaiVCJytA/JUniNsFZr6N41SfxuOgUYOLYlJL0Tg+dZYo0SA8YSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR07MB3147 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-15_02:2020-01-15, 2020-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 suspectscore=0 impostorscore=0 mlxscore=0 phishscore=0 spamscore=0 clxscore=1011 bulkscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001150105 Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 13:07:31 -0000 SSBzdXBwb3J0IHRoZSBjaGFydGVyIGFzIHdyaXR0ZW4uDQoNClBhdWwgQWRhaXINCkluZm9ibG94 DQoNCu+7v09uIDEvMTQvMjAsIDQ6MzggUE0sICJBZGQgb24gYmVoYWxmIG9mIFRvbW15IFBhdWx5 IiA8YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRwYXVseT00MGFwcGxlLmNvbUBk bWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQogICAgDQogICAgSSB3YW50ZWQg dG8gc2hhcmUgYW4gdXBkYXRlZCBwcm9wb3NhbCBmb3IgYW4gQUREIGNoYXJ0ZXIsIGJhc2VkIG9u IHRoZSBmZWVkYmFjayBhbmQgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBpbiB0aGUgcGFzdCBzZXZl cmFsIHdlZWtzLg0KICAgIA0KICAgIFRoaXMgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFsIHByb3Bv c2FsIHRoYXQgd2FzIHNlbnQgaW4gRGVjZW1iZXIsIHRha2luZyBpbnRvIGFjY291bnQgdmFyaW91 cyBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIEdsZW5uIERlZW4sIEFuZHJldyBDYW1wbGluZywg YW5kIEkgd29ya2VkIG9uIHRoaXMgcmV2aXNpb24gdG9nZXRoZXIgYW5kIGNhbWUgdG8gY29uc2Vu c3VzIG9uIGl0cyBjb250ZW50cy4NCiAgICANCiAgICBUaG91Z2h0cyBhbmQgY29tbWVudHMgYXJl IHdlbGNvbWUgYXMgYWx3YXlzIQ0KICAgIA0KICAgIChOb3RlIHRoYXQgdGhlIHByb3Bvc2VkIG5h bWUgb2YgdGhlIGdyb3VwIHdhcyBub3QgY2hhbmdlZCwgYW5kIGlzIGVudGlyZWx5IG9wZW4gdG8g YmlrZXNoZWRkaW5nLiBOYW1pbmcgaXMgaGFyZCEpDQogICAgDQogICAgQmVzdCwNCiAgICBUb21t eQ0KICAgIA0KICAgIA0KICAgIA0KICAgIEFkYXB0aXZlIEROUyBEaXNjb3ZlcnkgKEFERCkNCiAg ICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICBQcm9wb3NlZCBXb3Jr aW5nIEdyb3VwIENoYXJ0ZXINCiAgICANCiAgICBTZW5kaW5nIEROUyBtZXNzYWdlcyBvdmVyIGVu Y3J5cHRlZCB0cmFuc3BvcnRzLCBhcyBkZWZpbmVkIGluIEROUyBvdmVyDQogICAgVExTIChEb1Qp IFtSRkMgNzg1OF0gYW5kIEROUyBvdmVyIEhUVFBTIChEb0gpIFtSRkMgODQ4NF0sIHByb3ZpZGVz DQogICAgYmVuZWZpdHMgdG8gdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IG9mIEROUyBkYXRhLiBD bGllbnRzLCBzdWNoIGFzDQogICAgYXBwbGljYXRpb25zIGFuZCBob3N0IG9wZXJhdGluZyBzeXN0 ZW1zLCBoYXZlIHN0YXJ0ZWQgYWRvcHRpbmcgdGhlc2UNCiAgICBwcm90b2NvbHMgdG8gcHJvdmlk ZSB0aGVzZSB1c2VyIGJlbmVmaXRzLg0KICAgIA0KICAgIFRoaXMgd29ya2luZyBncm91cCB3aWxs IGZvY3VzIG9uIGRpc2NvdmVyeSBhbmQgc2VsZWN0aW9uIG9mIEROUyByZXNvbHZlcnMNCiAgICBi eSBETlMgY2xpZW50cyBpbiBhIHZhcmlldHkgb2YgbmV0d29ya2luZyBlbnZpcm9ubWVudHMsIGlu Y2x1ZGluZyBwdWJsaWMNCiAgICBuZXR3b3JrcywgcHJpdmF0ZSBuZXR3b3JrcywgYW5kIFZQTnM7 IHN1cHBvcnRpbmcgYm90aCBlbmNyeXB0ZWQgYW5kDQogICAgdW5lbmNyeXB0ZWQgcmVzb2x2ZXJz Lg0KICAgIA0KICAgIENsaWVudHMgYWRvcHRpbmcgZW5jcnlwdGVkIEROUyBwcm90b2NvbHMgbmVl ZCB0byBkZXRlcm1pbmUgd2hpY2ggRE5TDQogICAgc2VydmVycyBzdXBwb3J0IGVuY3J5cHRlZCB0 cmFuc3BvcnRzLCBhbmQgd2hpY2ggc2VydmVyIHRvIHVzZSBmb3Igc3BlY2lmaWMNCiAgICBxdWVy aWVzIGlmIG11bHRpcGxlIHNlcnZlcnMgYXJlIGF2YWlsYWJsZS4gVGhlc2UgZGVjaXNpb25zIGNh biB2YXJ5IGJhc2VkDQogICAgb24gdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQsIGFuZCBhbHNvIGJh c2VkIG9uIHRoZSBjb250ZW50IGFuZCBwdXJwb3NlIG9mDQogICAgdGhlIGNsaWVudCBxdWVyaWVz Lg0KICAgIA0KICAgIE5ldHdvcmsgb3BlcmF0b3JzIHRoYXQgc3RhcnQgb2ZmZXJpbmcgRE5TIGVu Y3J5cHRpb24gb24gdGhlaXIgc2VydmVycyBhbHNvDQogICAgbmVlZCBhIHdheSB0byBpbmRpY2F0 ZSB0aGlzIHN1cHBvcnQgdG8gY2xpZW50cy4gQ29tbXVuaWNhdGluZyBpbmZvcm1hdGlvbg0KICAg IGFib3V0IHJlc29sdmVyIGNvbmZpZ3VyYXRpb24gYW5kIGJlaGF2aW9yIGFsbG93cyBjbGllbnRz IHRvIG1ha2UgbW9yZQ0KICAgIGluZm9ybWVkIGRlY2lzaW9ucyBhYm91dCB3aGljaCBETlMgc2Vy dmVycyB0byB1c2UuIEZvciBleGFtcGxlLCBhIHJlc29sdmVyDQogICAgbWF5IGJlIGFibGUgdG8g cmVzb2x2ZSBwcml2YXRlIG9yIGxvY2FsIG5hbWVzIGFzIGEgc3BsaXQgRE5TIHNlcnZlci4NCiAg ICANCiAgICBUaGUgQWRhcHRpdmUgRE5TIERpc2NvdmVyeSAoQUREKSB3b3JraW5nIGdyb3VwIHdp bGwgd29yayBvbiB0aGUgZm9sbG93aW5nDQogICAgZGVsaXZlcmFibGVzOg0KICAgIA0KICAgIC0g ZGVmaW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGNsaWVudHMgdG8gZGlzY292ZXIgRE5TIHJl c29sdmVycywNCiAgICBpbmNsdWRpbmcgZW5jcnlwdGVkIEROUyBzZXJ2ZXJzLCB0aGF0IGFyZSBh dmFpbGFibGUgdG8gdGhlIGNsaWVudA0KICAgIGVpdGhlciBvbiB0aGUgcHVibGljIEludGVybmV0 IG9yIG9uIHByaXZhdGUgb3IgbG9jYWwgbmV0d29ya3M7DQogICAgDQogICAgLSBkZWZpbmUgYSBt ZWNoYW5pc20gdGhhdCBhbGxvd3MgY29tbXVuaWNhdGlvbiBvZiBETlMgcmVzb2x2ZXINCiAgICBp bmZvcm1hdGlvbiB0byBjbGllbnRzIGZvciB1c2UgaW4gc2VsZWN0aW9uIGRlY2lzaW9uczsNCiAg ICANCiAgICAtIGRldmVsb3AgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCB0aGF0IGRlc2NyaWJl cyBob3cgY2xpZW50DQogICAgYXBwbGljYXRpb25zIGFuZCBzeXN0ZW1zIGNhbiBtYW5hZ2Ugc2Vs ZWN0aW9uIG9mIEROUyByZXNvbHZlcnMNCiAgICBpbiB2YXJpb3VzIG5ldHdvcmsgZW52aXJvbm1l bnRzIGFuZCB1c2UgY2FzZXMuDQogICAgDQogICAgQW55IG1lY2hhbmlzbXMgdGhhdCBzcGVjaWZ5 IGludGVyYWN0aW9ucyBiZXR3ZWVuIGNsaWVudHMgYW5kDQogICAgc2VydmVycyBtdXN0IHByb3Zp ZGUgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgZXhwZWN0ZWQgb2YgSUVURg0KICAgIHByb3RvY29s cywgZS5nLiwgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24sIGludGVncml0eSBwcm90ZWN0aW9u LA0KICAgIGFuZCBhdXRoZW50aWNhdGlvbiB3aXRoIHN0cm9uZyB3b3JrIGZhY3Rvci4NCiAgICAN CiAgICBUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggZG5zb3AsIGRvaCwg YW5kIGRwcml2ZSBmb3IgYW55DQogICAgY2hhbmdlcyByZXF1aXJlZCBpbiBETlMgcHJvdG9jb2xz LiBJdCB3aWxsIGFsc28gd29yayB3aXRoIGNhcHBvcnQgdG8NCiAgICBlbnN1cmUgdGhhdCBzb2x1 dGlvbnMgYXJlIGFwcGxpY2FibGUgdG8gY2FwdGl2ZSBuZXR3b3Jrcy4NCiAgICANCiAgICAtLSAN CiAgICBBZGQgbWFpbGluZyBsaXN0DQogICAgQWRkQGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRk X187ISFKWXNnVFJBZzZaUSFZQVlXcHFJei01bW5WS0ZQMXVvbWFIblpxYWFQZU03amdfdDNiMkpF YjFSR0tJTERNdGx0djFlRDY4VkRoM1kkIA0KICAgIA0KDQo= From nobody Wed Jan 15 05:12:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F3A120232 for ; Wed, 15 Jan 2020 05:12:22 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.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 lpobiUxaX_M2 for ; Wed, 15 Jan 2020 05:12:17 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20708.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::708]) (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 A67B612022D for ; Wed, 15 Jan 2020 05:12:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H1Yv5rjL+zDDZhf70kC9zbDk7/m6hAS33RGbqarbn6CWGMWa1Y4JgmBpW+5d63GaA6IBHcV5V2QQe3a0P8gK9jSN4st8YyhGywNnSBlhbIc/wVE+j507/oj4yVt3HHifpWC8wQ4FUyeABblFKXfgiFqqK4ktun6ZgcQ5M8fufABY56K5Ms408Ywf84wGNQOyyZ/7lzQnYSXpNa1lttii5LIY0LsR9vjTNtXHYSwZSVq9lOFF1/OVbMIDGq+udiSs8Frnz2ax8Mdkp+qNgHDUHGpCbf4ahScNlPLzVAD6IyO5nQjvtVPotaASBahNPPb+qOml9U4gVEyNa/IR6qyRKA== 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=vZC3vjZI/AZjjpuoG0ky69vnlYOHQZ3UbTliMK/Vs2Y=; b=ZmtXVVhkY9W8Vh4xVLOnEAOIQIzPW1v1iETKhe58eSI8EAJWDALAyPqOU7SZkwsNULSeFtHz8CnDeElOHnnGdpODcue4PGYNUSbFB6lxjou+7O95ku07rHl0vUG7XO5zFJz560S/55Y0k0tnFIMAX4wbwAvC56DiPTtn6ZgnTWpHiavG5r4p823YSSvM+IpW9KGyd2PzW79T1TGpOtD3simmxomQ8gPJkL6wU8FZo5m7faL0+n1k33I2wNxJBRaWmO249g8HJLls7Bj88tnn5dvXFU1pCzxZJxSCtaiNEUAuzpBaVeh7v7D4xNIpfx+GDL2Nz/POKlg4mUHDJR8RSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vZC3vjZI/AZjjpuoG0ky69vnlYOHQZ3UbTliMK/Vs2Y=; b=OwdWQUgr98fmQd3a4HZdGoLxblLhrL2U680wdW9xsZnP7d8nE3Pa0SnR1F7+P6T+msqrrE2wqL6kb9m24eb463b2/XkuLgGi01ifmh8t4oY4N3qVa8YuagcYZCXYrFBNVEq/EaU0rYKJviqMaq5C3oe+x9rDsi1uuo6WQAml4H0= Received: from AM0PR06MB6435.eurprd06.prod.outlook.com (10.186.130.150) by AM0PR06MB6260.eurprd06.prod.outlook.com (20.179.254.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Wed, 15 Jan 2020 13:12:14 +0000 Received: from AM0PR06MB6435.eurprd06.prod.outlook.com ([fe80::7cfe:be7b:9e88:e034]) by AM0PR06MB6435.eurprd06.prod.outlook.com ([fe80::7cfe:be7b:9e88:e034%7]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 13:12:14 +0000 From: "Diego R. Lopez" To: Paul Adair , Tommy Pauly , ADD Mailing list Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVyytd/6T3SrWRvUmCDtd6EFv9VqfrsxqAgAASHAA= Date: Wed, 15 Jan 2020 13:12:13 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <0E6BAB56-3B54-4032-BD17-30770F242BB1@infoblox.com> In-Reply-To: <0E6BAB56-3B54-4032-BD17-30770F242BB1@infoblox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.12.200112 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [2001:878:302:6:1d51:3f08:29c1:f59c] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 12444cbb-2789-4f2f-95e1-08d799bc89d4 x-ms-traffictypediagnostic: AM0PR06MB6260: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(136003)(39860400002)(366004)(396003)(189003)(199004)(8676002)(45080400002)(478600001)(66946007)(91956017)(71200400001)(5660300002)(76116006)(66446008)(110136005)(64756008)(66476007)(66556008)(316002)(8936002)(186003)(86362001)(53546011)(6506007)(2616005)(15650500001)(966005)(66574012)(786003)(81166006)(81156014)(33656002)(6486002)(2906002)(36756003)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR06MB6260; H:AM0PR06MB6435.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TkJB6dNNJfU0HGeJddNZMJwYF+2yLc0WSuhv8T2DUpuMUBCnHddf1zR7LGcf4n3sG3JC6abaWHWDh8ga5CNOMNAix7kX8PZx0Fo1bpzLWlJSfQakwo+O7ZHU7+H8oRw3mQ1FEuDOxcp3t//RCQ3wrV0ZScBMXxoSIatAbn1aWf02HqW3J+EofkITRwLccNeG0rNFp1YuKZ45fiUPBqzHaNb+XcP26jiwO9D67zy2Y+Wn4zNg1eMbcal4QbvnMFcp3Fam38DdJyu0nDnzdgdUAuYXFzhRYjMxKChVG1PN+Zf9VSj5JuxsIy1y7ycK7+CoWtmj1SxLECv45wB3NsP0/b6CpFLrztgsKlNEim1iPpY97NmXX5vf8yAQ3Mc3viO6fa+l59pmLmoDEyhmpkJdaXE7HVjrOrEcnESH1ZMB8cGLJiFEzTyRne5IxPn81O197eKPzziLBaouCjm6am7gaZVcO7iRdERUoRZ3H+pZ6IuOI7FXDmGXJDdVdYoY6ydEwdxKzL7sSdtM/4411DpCCQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5A1F7BD7CB376E4280A0BD596ACBE2C3@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12444cbb-2789-4f2f-95e1-08d799bc89d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 13:12:13.5940 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U+35CA3XYzeHMa1tj/h40Ee8Nn0qz9QynX8jczE4F8PNWX8Y8Z8eLjNFKL3p2iVTKCRtP0i8XADiD3Ihr5lBQjdKtau6QzQxYTA6yX4yvc8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR06MB6260 Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 13:12:22 -0000 KzENCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRy IERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cHM6Ly93d3cubGlua2VkaW4uY29t L2luL2RyMmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20NClRl bDogICAgICAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogICszNCA2ODIgMDUxIDA5MQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrvu79PbiAxNS8wMS8yMDIwLCAxNDow NywgIkFkZCBvbiBiZWhhbGYgb2YgUGF1bCBBZGFpciIgPGFkZC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBwYWRhaXJAaW5mb2Jsb3guY29tPiB3cm90ZToNCg0KICAgIEkgc3VwcG9ydCB0 aGUgY2hhcnRlciBhcyB3cml0dGVuLg0KDQogICAgUGF1bCBBZGFpcg0KICAgIEluZm9ibG94DQoN CiAgICBPbiAxLzE0LzIwLCA0OjM4IFBNLCAiQWRkIG9uIGJlaGFsZiBvZiBUb21teSBQYXVseSIg PGFkZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0cGF1bHk9NDBhcHBsZS5jb21AZG1h cmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgICAgIEhpIGFsbCwNCg0KICAgICAgICBJIHdhbnRl ZCB0byBzaGFyZSBhbiB1cGRhdGVkIHByb3Bvc2FsIGZvciBhbiBBREQgY2hhcnRlciwgYmFzZWQg b24gdGhlIGZlZWRiYWNrIGFuZCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGluIHRoZSBwYXN0IHNl dmVyYWwgd2Vla3MuDQoNCiAgICAgICAgVGhpcyBpcyBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgcHJv cG9zYWwgdGhhdCB3YXMgc2VudCBpbiBEZWNlbWJlciwgdGFraW5nIGludG8gYWNjb3VudCB2YXJp b3VzIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gR2xlbm4gRGVlbiwgQW5kcmV3IENhbXBsaW5n LCBhbmQgSSB3b3JrZWQgb24gdGhpcyByZXZpc2lvbiB0b2dldGhlciBhbmQgY2FtZSB0byBjb25z ZW5zdXMgb24gaXRzIGNvbnRlbnRzLg0KDQogICAgICAgIFRob3VnaHRzIGFuZCBjb21tZW50cyBh cmUgd2VsY29tZSBhcyBhbHdheXMhDQoNCiAgICAgICAgKE5vdGUgdGhhdCB0aGUgcHJvcG9zZWQg bmFtZSBvZiB0aGUgZ3JvdXAgd2FzIG5vdCBjaGFuZ2VkLCBhbmQgaXMgZW50aXJlbHkgb3BlbiB0 byBiaWtlc2hlZGRpbmcuIE5hbWluZyBpcyBoYXJkISkNCg0KICAgICAgICBCZXN0LA0KICAgICAg ICBUb21teQ0KDQoNCg0KICAgICAgICBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpDQogICAg ICAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgICBQcm9wb3Nl ZCBXb3JraW5nIEdyb3VwIENoYXJ0ZXINCg0KICAgICAgICBTZW5kaW5nIEROUyBtZXNzYWdlcyBv dmVyIGVuY3J5cHRlZCB0cmFuc3BvcnRzLCBhcyBkZWZpbmVkIGluIEROUyBvdmVyDQogICAgICAg IFRMUyAoRG9UKSBbUkZDIDc4NThdIGFuZCBETlMgb3ZlciBIVFRQUyAoRG9IKSBbUkZDIDg0ODRd LCBwcm92aWRlcw0KICAgICAgICBiZW5lZml0cyB0byB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kg b2YgRE5TIGRhdGEuIENsaWVudHMsIHN1Y2ggYXMNCiAgICAgICAgYXBwbGljYXRpb25zIGFuZCBo b3N0IG9wZXJhdGluZyBzeXN0ZW1zLCBoYXZlIHN0YXJ0ZWQgYWRvcHRpbmcgdGhlc2UNCiAgICAg ICAgcHJvdG9jb2xzIHRvIHByb3ZpZGUgdGhlc2UgdXNlciBiZW5lZml0cy4NCg0KICAgICAgICBU aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBmb2N1cyBvbiBkaXNjb3ZlcnkgYW5kIHNlbGVjdGlvbiBv ZiBETlMgcmVzb2x2ZXJzDQogICAgICAgIGJ5IEROUyBjbGllbnRzIGluIGEgdmFyaWV0eSBvZiBu ZXR3b3JraW5nIGVudmlyb25tZW50cywgaW5jbHVkaW5nIHB1YmxpYw0KICAgICAgICBuZXR3b3Jr cywgcHJpdmF0ZSBuZXR3b3JrcywgYW5kIFZQTnM7IHN1cHBvcnRpbmcgYm90aCBlbmNyeXB0ZWQg YW5kDQogICAgICAgIHVuZW5jcnlwdGVkIHJlc29sdmVycy4NCg0KICAgICAgICBDbGllbnRzIGFk b3B0aW5nIGVuY3J5cHRlZCBETlMgcHJvdG9jb2xzIG5lZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIERO Uw0KICAgICAgICBzZXJ2ZXJzIHN1cHBvcnQgZW5jcnlwdGVkIHRyYW5zcG9ydHMsIGFuZCB3aGlj aCBzZXJ2ZXIgdG8gdXNlIGZvciBzcGVjaWZpYw0KICAgICAgICBxdWVyaWVzIGlmIG11bHRpcGxl IHNlcnZlcnMgYXJlIGF2YWlsYWJsZS4gVGhlc2UgZGVjaXNpb25zIGNhbiB2YXJ5IGJhc2VkDQog ICAgICAgIG9uIHRoZSBuZXR3b3JrIGVudmlyb25tZW50LCBhbmQgYWxzbyBiYXNlZCBvbiB0aGUg Y29udGVudCBhbmQgcHVycG9zZSBvZg0KICAgICAgICB0aGUgY2xpZW50IHF1ZXJpZXMuDQoNCiAg ICAgICAgTmV0d29yayBvcGVyYXRvcnMgdGhhdCBzdGFydCBvZmZlcmluZyBETlMgZW5jcnlwdGlv biBvbiB0aGVpciBzZXJ2ZXJzIGFsc28NCiAgICAgICAgbmVlZCBhIHdheSB0byBpbmRpY2F0ZSB0 aGlzIHN1cHBvcnQgdG8gY2xpZW50cy4gQ29tbXVuaWNhdGluZyBpbmZvcm1hdGlvbg0KICAgICAg ICBhYm91dCByZXNvbHZlciBjb25maWd1cmF0aW9uIGFuZCBiZWhhdmlvciBhbGxvd3MgY2xpZW50 cyB0byBtYWtlIG1vcmUNCiAgICAgICAgaW5mb3JtZWQgZGVjaXNpb25zIGFib3V0IHdoaWNoIERO UyBzZXJ2ZXJzIHRvIHVzZS4gRm9yIGV4YW1wbGUsIGEgcmVzb2x2ZXINCiAgICAgICAgbWF5IGJl IGFibGUgdG8gcmVzb2x2ZSBwcml2YXRlIG9yIGxvY2FsIG5hbWVzIGFzIGEgc3BsaXQgRE5TIHNl cnZlci4NCg0KICAgICAgICBUaGUgQWRhcHRpdmUgRE5TIERpc2NvdmVyeSAoQUREKSB3b3JraW5n IGdyb3VwIHdpbGwgd29yayBvbiB0aGUgZm9sbG93aW5nDQogICAgICAgIGRlbGl2ZXJhYmxlczoN Cg0KICAgICAgICAtIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBjbGllbnRzIHRvIGRp c2NvdmVyIEROUyByZXNvbHZlcnMsDQogICAgICAgIGluY2x1ZGluZyBlbmNyeXB0ZWQgRE5TIHNl cnZlcnMsIHRoYXQgYXJlIGF2YWlsYWJsZSB0byB0aGUgY2xpZW50DQogICAgICAgIGVpdGhlciBv biB0aGUgcHVibGljIEludGVybmV0IG9yIG9uIHByaXZhdGUgb3IgbG9jYWwgbmV0d29ya3M7DQoN CiAgICAgICAgLSBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgY29tbXVuaWNhdGlvbiBv ZiBETlMgcmVzb2x2ZXINCiAgICAgICAgaW5mb3JtYXRpb24gdG8gY2xpZW50cyBmb3IgdXNlIGlu IHNlbGVjdGlvbiBkZWNpc2lvbnM7DQoNCiAgICAgICAgLSBkZXZlbG9wIGFuIGluZm9ybWF0aW9u YWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgaG93IGNsaWVudA0KICAgICAgICBhcHBsaWNhdGlv bnMgYW5kIHN5c3RlbXMgY2FuIG1hbmFnZSBzZWxlY3Rpb24gb2YgRE5TIHJlc29sdmVycw0KICAg ICAgICBpbiB2YXJpb3VzIG5ldHdvcmsgZW52aXJvbm1lbnRzIGFuZCB1c2UgY2FzZXMuDQoNCiAg ICAgICAgQW55IG1lY2hhbmlzbXMgdGhhdCBzcGVjaWZ5IGludGVyYWN0aW9ucyBiZXR3ZWVuIGNs aWVudHMgYW5kDQogICAgICAgIHNlcnZlcnMgbXVzdCBwcm92aWRlIHRoZSBzZWN1cml0eSBwcm9w ZXJ0aWVzIGV4cGVjdGVkIG9mIElFVEYNCiAgICAgICAgcHJvdG9jb2xzLCBlLmcuLCBjb25maWRl bnRpYWxpdHkgcHJvdGVjdGlvbiwgaW50ZWdyaXR5IHByb3RlY3Rpb24sDQogICAgICAgIGFuZCBh dXRoZW50aWNhdGlvbiB3aXRoIHN0cm9uZyB3b3JrIGZhY3Rvci4NCg0KICAgICAgICBUaGlzIHdv cmtpbmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggZG5zb3AsIGRvaCwgYW5kIGRwcml2ZSBm b3IgYW55DQogICAgICAgIGNoYW5nZXMgcmVxdWlyZWQgaW4gRE5TIHByb3RvY29scy4gSXQgd2ls bCBhbHNvIHdvcmsgd2l0aCBjYXBwb3J0IHRvDQogICAgICAgIGVuc3VyZSB0aGF0IHNvbHV0aW9u cyBhcmUgYXBwbGljYWJsZSB0byBjYXB0aXZlIG5ldHdvcmtzLg0KDQogICAgICAgIC0tDQogICAg ICAgIEFkZCBtYWlsaW5nIGxpc3QNCiAgICAgICAgQWRkQGlldGYub3JnDQogICAgICAgIGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FkZF9fOyEhSllzZ1RSQWc2WlEhWUFZV3BxSXotNW1uVktGUDF1b21hSG5acWFhUGVNN2pn X3QzYjJKRWIxUkdLSUxETXRsdHYxZUQ2OFZEaDNZJA0KDQoNCiAgICAtLQ0KICAgIEFkZCBtYWls aW5nIGxpc3QNCiAgICBBZGRAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FkZA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24g aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0 aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBu b3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVs ZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNp dmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHBy aXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBk ZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwg dXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28g cG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3Vh IGRlc3RydWnDp8Ojbw0K From nobody Wed Jan 15 07:14:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D63120241 for ; Wed, 15 Jan 2020 07:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XTwSExXm13t for ; Wed, 15 Jan 2020 07:13:19 -0800 (PST) Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 E88E912083B for ; Wed, 15 Jan 2020 07:13:12 -0800 (PST) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa2.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id 00FFDBv9011094 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 15:13:12 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Jan 2020 07:13:10 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Wed, 15 Jan 2020 07:13:10 -0800 From: Paul Hoffman To: Tommy Pauly CC: ADD Mailing list Thread-Topic: [Ext] [Add] Updated charter proposal for ADD Thread-Index: AQHVyytcQlPGU7pViE+lwCrvXwWZoKfsXFyA Date: Wed, 15 Jan 2020 15:13:09 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_4CD2FC02-E3E6-4723-9493-EC795FE19441"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-15_02:, , signatures=0 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 15:13:26 -0000 --Apple-Mail=_4CD2FC02-E3E6-4723-9493-EC795FE19441 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The following paragraph in the proposed charter is impossible to meet = for the vast majority of use cases that have been discussed on this = list: Any mechanisms that specify interactions between clients and servers must provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor. Any mechanism whose understanding of the network and network services = comes from interactions that were not cryptographically authenticated = (such as DHCP and RA) cannot meet those requirements. The presence of that paragraph will basically stop work being done in = the WG once it is chartered. Please strongly consider removing it. = Without that paragraph, the charter seems fine. --Paul Hoffman= --Apple-Mail=_4CD2FC02-E3E6-4723-9493-EC795FE19441 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMTE1MTUxMzA5WjAvBgkqhkiG9w0BCQQxIgQgBLPIrdm/EiyoRKb4Rsj7oAyXhnqM srrBu7ajTma1AHwwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBACFkPBcbDQJ40nWgYNcuuBveCjwy4hVpPaLvoWEmrtqM xcqY65HkDfHZC2i+nj0slNlM3+vaIYcDiIGnfkygJ73VZLSBv1oUIc1r23yd6dykDYUDgPXfkYky olXYLzMvHepbaMyqmk+g5Kovx/G/gxaCH6dDpfp+SMFcy0oDnfOK8O4nN6uUrQP2CrzcYraC+AoG GV5NZg1nspFCmDjf6oexEJtvMr0fLSMkEGpYP4wHJQNcKi3zy9Lgiqd7GsMFoRaCL7WDRgtbdrp+ ivwMg9DABDK6CDD3dVR6vgWsthz6zax1yXZ36VecCHTRxpoobzAnDnqlzF4gRI1UXurWWVEAAAAA AAA= --Apple-Mail=_4CD2FC02-E3E6-4723-9493-EC795FE19441-- From nobody Wed Jan 15 07:38:19 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B92120091 for ; Wed, 15 Jan 2020 07:37:32 -0800 (PST) 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_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=xfijBer6; dkim=pass (2048-bit key) header.d=comcast.com header.b=5GquIW49; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=BsJ3q/yc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X735pAT1Em_L for ; Wed, 15 Jan 2020 07:37:27 -0800 (PST) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (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 9608D120025 for ; Wed, 15 Jan 2020 07:37:27 -0800 (PST) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00FFb8sF006287 for ; Wed, 15 Jan 2020 10:37:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=4K0vDjZcoVGrVYIwBO0CTg/ijxAal+4myiscICZECeQ=; b=xfijBer6Hj6bc0E4zA/7Hd4kZJ+mqmoCbpvLQt5lFyHYRUwjxyickDl1acvutgZtP9dU 9pzHarwImFcaxnaTr3doX3fHCPPT/icqE1yvkfS5DNvQPFAVbI+NPNDncyYZ4oDnooc7 6Cz8HHS8WbprbPmj3pMMjH+HKjyZcyqY/wPDJ2TtLN1II2ceYUck/EtxgKVcjrxyWUWr YYdWkEJg4u578OyV4Zemzumw6n9XMB/PhbqwppxHTA/bFjInN3hMip5peEmHz6oqcU9J upF8TpIZ1j+DHh2WBh3DVipCKhQJg/sTNZkSC7MUysj1Orag/+yjwpEEdVnxUxgAemit nQ== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0b-00143702.pphosted.com with ESMTP id 2xgw1ad3uq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 Jan 2020 10:37:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1579102643; x=2443016243; 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=4K0vDjZcoVGrVYIwBO0CTg/ijxAal+4myiscICZECeQ=; b=5GquIW49FVAYk/ysslBMaxnWsfXWT3Dv6eUiLupzXX499NXEG0QXIKNABthiYLJF Hvl2pzW1JDoxgT0b1+wzAGmaAYaUg7otTMSC4BOwUMTd7VV/MzoXTq/yuY2vLv0d FKvnkLBGxihXSDI/hLQb6AcWv8OKY4Rr5KMxjQTGCF6dMHcjfxYbSAwME+cI4TLw GITAE6D3OW9+qiZi7oyLFYX8CUoo8BwfOnKuFQHmS8jYAQL45e5LOA+m+yp8yYx9 j2DuuYki5o1LnhOoRZeGxRf+eLbK5ZoIeDHucFr+e34URLwG23hOa3qwTibltdHT /bi5ltDY/aH3s8J9MBxT8g==; X-AuditID: 60729ed4-237ff7000000bc72-81-5e1f31b3dc2e Received: from COPDCEX22.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 ED.26.48242.3B13F1E5; Wed, 15 Jan 2020 08:37:23 -0700 (MST) Received: from COPDCEX13.cable.comcast.com (147.191.124.144) by COPDCEX22.cable.comcast.com (147.191.124.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 08:37:22 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 15 Jan 2020 08:37:22 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.171) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 15 Jan 2020 10:37:07 -0500 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com (10.174.117.21) by BN6PR1101MB2163.namprd11.prod.outlook.com (10.174.116.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Wed, 15 Jan 2020 15:37:05 +0000 Received: from BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff]) by BN6PR1101MB2195.namprd11.prod.outlook.com ([fe80::8ba:8611:cdf:1cff%6]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 15:37:05 +0000 From: "Livingood, Jason" To: Tommy Pauly , ADD Mailing list Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVyyt0XhPiRXWqRUiQK5UHo0jSBafriR0A Date: Wed, 15 Jan 2020 15:37:05 +0000 Message-ID: <7F6FFAC3-0851-4334-B859-A412131FD91A@cable.comcast.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-originating-ip: [2001:558:1438:13:c1d2:8cbc:7ffa:bcd0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d13a64a2-0e36-4313-ae27-08d799d0c653 x-ms-traffictypediagnostic: BN6PR1101MB2163: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(39860400002)(396003)(376002)(366004)(346002)(189003)(199004)(2616005)(316002)(64756008)(66476007)(966005)(186003)(66556008)(66946007)(66446008)(76116006)(478600001)(91956017)(33656002)(15650500001)(2906002)(81156014)(5660300002)(66574012)(110136005)(8936002)(6512007)(71200400001)(6506007)(8676002)(6486002)(81166006)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1101MB2163; H:BN6PR1101MB2195.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: KvWFbZCM1Td13D23J6W5MBo0FGG/5RM9M//nLHX+ZsTOdo4sBEWgTRvH1xaFMY5qeEWyobrfgU0hoXMSLfuPBi5Th0XHuQO1HeMcy6g+YN5Tx9UUmQPEhhawA8LCnWNddpYT/QTY3AjPbT9qzYuPqeI+LcDypduuIcnrJXrVZU0/i+3YaRpyE0QDvTUdq23qgzCakY+xEIPbF4bOTGVNhp0G/Ixm8n86vEVKDHpqLlUb7SdXIHkJs46KCLRz95uaF1lBLBFyfZauU8rSfaVCBVYowIP8AmvgJA8j74hJOV+ZkXLxr1BElKTAaYKnBw69ubBgjEzqP7VDNw/jy+UnkBbPsRdkqkvzClFI71cxCs3PZB0uMwRCqCr2h0Qrl+fwE2yj5+IG6bthUCT5XCuuH/cXNUwda6D++kNH6DwtOfSyTltBYAd2rM8vr5SzzBQydBpCbKgqTdBoWEf3fg7Rhskkkhs+kEt2a4NBHz9BuR1gdXtjN6l1NWJr3MWvkums+Bpe4Iz2Xx3tZIz+Jyh93w== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mU5/kiR+bVnvQziTQhnMsC+Tgl29lpK+Dh0OIYGq00prKijoOJUEFqthiXZhXzalcdiuX/N9ZUIXF5Xzcv0HiQkDpVW23AxDEPkhxBtqWCXwKcIQEYcGg8NebY52rv5zpNHBWqTJjpK8Wgm0YeodDlYLWwcsgGjuZr2YkWa2boutZztazLieMEOp4j5wjXWCX+n7f20hjFw6+ezvn0hwnxAgTZF1QRSss1tdHmqHmOwwQ9JhcVvhiKek+UHcFnCG+wJ/Di4j53WETjlRz1+pnWkVO63BtnU69iV89auawn+RAyeDuCwYQurY7iQBYt/v0/yyKXpoZvvh88T3wyOvDA== 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=VQ9z9fThzq6SnuXhorNU6BiNNcorALRxiKDqUjbP6ek=; b=jVLUpJb+ucb9aGhr+qB5mIpJgOo7S8PSd8XlcRVr7GRmT7py56xRnX8VGAoim4quPTTHL/X1ZoMoFeFy1b1ogiGN0HNlshJ6TXBi/tqCAyN8TbGYb4G1WeV+oHrT+w8USQWT225KhjqqsHWVO4PXFnkxB9NFnHYJGs3OFSfV+nyaNem9oxmxkHS94wvbBiLM0GOcnFJL9qklqXs4/0IUBWAzjBlsBlgh5jwOSmUsHG5Qv1iMXeFpkS0LQUNQQqhD0Zyipn0a3Q7QMWitZq5ZH2xCeY9BDvo9M25ndhDNuJOevijDmIJVagqHbTHsXpLiItsHhkOidM/mdGsBD5ZRTw== 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=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VQ9z9fThzq6SnuXhorNU6BiNNcorALRxiKDqUjbP6ek=; b=BsJ3q/ycCLwBJDPXNqdc3bduoKbTJKyW4LyBe6T24WKsBUV2XhCBozwfd7LMPHJ6nlEHHfL7H88SIGzUHoW0F+S55lYSZnrA9McxT6/DnS1uu2KXY/oajbP6qcq5kaNqE3aTW7f6IYn8HtlvBUUlDtblm19llHQaQemDX9mQljU= x-ms-exchange-crosstenant-network-message-id: d13a64a2-0e36-4313-ae27-08d799d0c653 x-ms-exchange-crosstenant-originalarrivaltime: 15 Jan 2020 15:37:05.3835 (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: ASYVIVszCny71VnkjqzqOT0qx2IqlrjZ9xYze9aoznNgmVPoTI1Q3aeqqMjfirZyqQ19jD0Bmlb+UzebRL3OE4Cips1k6B6fwDvrsTK21jo= x-ms-exchange-transport-crosstenantheadersstamped: BN6PR1101MB2163 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <1DC60245DE98B3419B7A3DE87321102E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHKsWRmVeSWpSXmKPExsWSUDRnsu5mQ/k4g8/v9Sz+n17HZtEz6RWz A5PHiWVXWD2WLPnJFMAU1cBoU5JRlJpY4pKalppXnGrHpYABbJJS0/KLUl0Ti3Iqg1JzUhOx KwOpTEnNySxLLdLHaow+VnMSupgyFp86w1zwR73i4ZUvTA2MP9S6GDk5JARMJB5cXcLaxcjF ISRwmEni/4Zl7BDOIUaJiW+/MIJUCQncYZTYMlUUInGSUeJIVxszhDONSWLG+U5GCOcRo8SO fQ/BWtgEzCTuLrzCDGKLCIRJ7FnexAZiCwsYS/y73sYCETeReP3vJzuEbSSxeNoTsF4WAVWJ 7s5+VhCbV8BF4vrrz6wQZ9hI7HswCayXU8BWYt39d2D1jAJiEt9PrWECsZkFxCVuPZnPBPGc gMSSPeeZIWxRiZeP/4HNERXQl7h3fTVUb4rE4q5FUPUWEh9mPmKBsGUlLs3vZoSwfSWWNqxh g7B1JL6emANVky/xcsY0qBo1iRtvOoB2cQDZMhJHZrmCwkRCYDqLxPsdN5hA4kICWRJvr9pB lMtJrOp9yDKB0WQWkqtnAVUxC2hKrN+lD2F6SOzriYGoUJSY0v2QfRY4TAQlTs58wrKAkXUV I5+lmZ6hoYmeoamFnpGh0SZGcKqcd2UH4+XpHocYBTgYlXh4RcXk44RYE8uKK3OB0crBrCTC e3KGbJwQb0piZVVqUX58UWlOavEhRmkOFiVxXjbbX7FCAumJJanZqakFqUUwWSYOTqkGRjXV 81xt3k7vWkOt/qcaZ4jf3SKm3qVo9DreccHBqi0lx/5Y1W3zftLmz+WeFsEjOUP62E6uK9pL g5ySfeNjnLqMTz2R1Dn3o6AjcKbBhJO/X3/0jdzTZ3UjNuT8sn+FVvl3LuzLe3b7qYhR96Ol MvdTfn93suU9Yea0Kuq72Y89l3JsrlQUKLEUZyQaajEXFScCALx/+lSRAwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-15_02:2020-01-15, 2020-01-15 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 15:37:33 -0000 SSBhbHNvIHN1cHBvcnQgdGhpcyBjaGFydGVyICYgYXBwcmVjaWF0ZSB0aGUgaGFyZCB3b3JrIGRv bmUgdG8gdHJ5IHRvIG1vdmUgdG8gYSBjb25zZW5zdXMgdmlldyAodGhhbmtzIFRvbW15ICYgR2xl bm4gaW4gcGFydGljdWxhcikuDQoNCkEgbnVtYmVyIG9mIGZvbGtzIGhhdmUgb2JqZWN0ZWQgdG8g dGhlICJBbnkgbWVjaGFuaXNtLi4uIiBwYXJhZ3JhcGggLSBzbyByZW1vdmFsIG9mIHRoYXQgc2Vl bXMgZmluZS4NCg0KSmFzb24NCg0K77u/T24gMS8xNC8yMCwgNTozOSBQTSwgIkFkZCBvbiBiZWhh bGYgb2YgVG9tbXkgUGF1bHkiIDxhZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdHBh dWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0KICAgIEhpIGFsbCwNCg0K ICAgIEkgd2FudGVkIHRvIHNoYXJlIGFuIHVwZGF0ZWQgcHJvcG9zYWwgZm9yIGFuIEFERCBjaGFy dGVyLCBiYXNlZCBvbiB0aGUgZmVlZGJhY2sgYW5kIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgaW4g dGhlIHBhc3Qgc2V2ZXJhbCB3ZWVrcy4NCg0KICAgIFRoaXMgaXMgYmFzZWQgb24gdGhlIG9yaWdp bmFsIHByb3Bvc2FsIHRoYXQgd2FzIHNlbnQgaW4gRGVjZW1iZXIsIHRha2luZyBpbnRvIGFjY291 bnQgdmFyaW91cyBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIEdsZW5uIERlZW4sIEFuZHJldyBD YW1wbGluZywgYW5kIEkgd29ya2VkIG9uIHRoaXMgcmV2aXNpb24gdG9nZXRoZXIgYW5kIGNhbWUg dG8gY29uc2Vuc3VzIG9uIGl0cyBjb250ZW50cy4NCg0KICAgIFRob3VnaHRzIGFuZCBjb21tZW50 cyBhcmUgd2VsY29tZSBhcyBhbHdheXMhDQoNCiAgICAoTm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBu YW1lIG9mIHRoZSBncm91cCB3YXMgbm90IGNoYW5nZWQsIGFuZCBpcyBlbnRpcmVseSBvcGVuIHRv IGJpa2VzaGVkZGluZy4gTmFtaW5nIGlzIGhhcmQhKQ0KDQogICAgQmVzdCwNCiAgICBUb21teQ0K DQoNCg0KICAgIEFkYXB0aXZlIEROUyBEaXNjb3ZlcnkgKEFERCkNCiAgICA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICBQcm9wb3NlZCBXb3JraW5nIEdyb3VwIENoYXJ0 ZXINCg0KICAgIFNlbmRpbmcgRE5TIG1lc3NhZ2VzIG92ZXIgZW5jcnlwdGVkIHRyYW5zcG9ydHMs IGFzIGRlZmluZWQgaW4gRE5TIG92ZXINCiAgICBUTFMgKERvVCkgW1JGQyA3ODU4XSBhbmQgRE5T IG92ZXIgSFRUUFMgKERvSCkgW1JGQyA4NDg0XSwgcHJvdmlkZXMNCiAgICBiZW5lZml0cyB0byB0 aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgb2YgRE5TIGRhdGEuIENsaWVudHMsIHN1Y2ggYXMNCiAg ICBhcHBsaWNhdGlvbnMgYW5kIGhvc3Qgb3BlcmF0aW5nIHN5c3RlbXMsIGhhdmUgc3RhcnRlZCBh ZG9wdGluZyB0aGVzZQ0KICAgIHByb3RvY29scyB0byBwcm92aWRlIHRoZXNlIHVzZXIgYmVuZWZp dHMuDQoNCiAgICBUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBmb2N1cyBvbiBkaXNjb3ZlcnkgYW5k IHNlbGVjdGlvbiBvZiBETlMgcmVzb2x2ZXJzDQogICAgYnkgRE5TIGNsaWVudHMgaW4gYSB2YXJp ZXR5IG9mIG5ldHdvcmtpbmcgZW52aXJvbm1lbnRzLCBpbmNsdWRpbmcgcHVibGljDQogICAgbmV0 d29ya3MsIHByaXZhdGUgbmV0d29ya3MsIGFuZCBWUE5zOyBzdXBwb3J0aW5nIGJvdGggZW5jcnlw dGVkIGFuZA0KICAgIHVuZW5jcnlwdGVkIHJlc29sdmVycy4NCg0KICAgIENsaWVudHMgYWRvcHRp bmcgZW5jcnlwdGVkIEROUyBwcm90b2NvbHMgbmVlZCB0byBkZXRlcm1pbmUgd2hpY2ggRE5TDQog ICAgc2VydmVycyBzdXBwb3J0IGVuY3J5cHRlZCB0cmFuc3BvcnRzLCBhbmQgd2hpY2ggc2VydmVy IHRvIHVzZSBmb3Igc3BlY2lmaWMNCiAgICBxdWVyaWVzIGlmIG11bHRpcGxlIHNlcnZlcnMgYXJl IGF2YWlsYWJsZS4gVGhlc2UgZGVjaXNpb25zIGNhbiB2YXJ5IGJhc2VkDQogICAgb24gdGhlIG5l dHdvcmsgZW52aXJvbm1lbnQsIGFuZCBhbHNvIGJhc2VkIG9uIHRoZSBjb250ZW50IGFuZCBwdXJw b3NlIG9mDQogICAgdGhlIGNsaWVudCBxdWVyaWVzLg0KDQogICAgTmV0d29yayBvcGVyYXRvcnMg dGhhdCBzdGFydCBvZmZlcmluZyBETlMgZW5jcnlwdGlvbiBvbiB0aGVpciBzZXJ2ZXJzIGFsc28N CiAgICBuZWVkIGEgd2F5IHRvIGluZGljYXRlIHRoaXMgc3VwcG9ydCB0byBjbGllbnRzLiBDb21t dW5pY2F0aW5nIGluZm9ybWF0aW9uDQogICAgYWJvdXQgcmVzb2x2ZXIgY29uZmlndXJhdGlvbiBh bmQgYmVoYXZpb3IgYWxsb3dzIGNsaWVudHMgdG8gbWFrZSBtb3JlDQogICAgaW5mb3JtZWQgZGVj aXNpb25zIGFib3V0IHdoaWNoIEROUyBzZXJ2ZXJzIHRvIHVzZS4gRm9yIGV4YW1wbGUsIGEgcmVz b2x2ZXINCiAgICBtYXkgYmUgYWJsZSB0byByZXNvbHZlIHByaXZhdGUgb3IgbG9jYWwgbmFtZXMg YXMgYSBzcGxpdCBETlMgc2VydmVyLg0KDQogICAgVGhlIEFkYXB0aXZlIEROUyBEaXNjb3Zlcnkg KEFERCkgd29ya2luZyBncm91cCB3aWxsIHdvcmsgb24gdGhlIGZvbGxvd2luZw0KICAgIGRlbGl2 ZXJhYmxlczoNCg0KICAgIC0gZGVmaW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGNsaWVudHMg dG8gZGlzY292ZXIgRE5TIHJlc29sdmVycywNCiAgICBpbmNsdWRpbmcgZW5jcnlwdGVkIEROUyBz ZXJ2ZXJzLCB0aGF0IGFyZSBhdmFpbGFibGUgdG8gdGhlIGNsaWVudA0KICAgIGVpdGhlciBvbiB0 aGUgcHVibGljIEludGVybmV0IG9yIG9uIHByaXZhdGUgb3IgbG9jYWwgbmV0d29ya3M7DQoNCiAg ICAtIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBjb21tdW5pY2F0aW9uIG9mIEROUyBy ZXNvbHZlcg0KICAgIGluZm9ybWF0aW9uIHRvIGNsaWVudHMgZm9yIHVzZSBpbiBzZWxlY3Rpb24g ZGVjaXNpb25zOw0KDQogICAgLSBkZXZlbG9wIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhh dCBkZXNjcmliZXMgaG93IGNsaWVudA0KICAgIGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVtcyBjYW4g bWFuYWdlIHNlbGVjdGlvbiBvZiBETlMgcmVzb2x2ZXJzDQogICAgaW4gdmFyaW91cyBuZXR3b3Jr IGVudmlyb25tZW50cyBhbmQgdXNlIGNhc2VzLg0KDQogICAgQW55IG1lY2hhbmlzbXMgdGhhdCBz cGVjaWZ5IGludGVyYWN0aW9ucyBiZXR3ZWVuIGNsaWVudHMgYW5kDQogICAgc2VydmVycyBtdXN0 IHByb3ZpZGUgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgZXhwZWN0ZWQgb2YgSUVURg0KICAgIHBy b3RvY29scywgZS5nLiwgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24sIGludGVncml0eSBwcm90 ZWN0aW9uLA0KICAgIGFuZCBhdXRoZW50aWNhdGlvbiB3aXRoIHN0cm9uZyB3b3JrIGZhY3Rvci4N Cg0KICAgIFRoaXMgd29ya2luZyBncm91cCB3aWxsIGNvb3JkaW5hdGUgd2l0aCBkbnNvcCwgZG9o LCBhbmQgZHByaXZlIGZvciBhbnkNCiAgICBjaGFuZ2VzIHJlcXVpcmVkIGluIEROUyBwcm90b2Nv bHMuIEl0IHdpbGwgYWxzbyB3b3JrIHdpdGggY2FwcG9ydCB0bw0KICAgIGVuc3VyZSB0aGF0IHNv bHV0aW9ucyBhcmUgYXBwbGljYWJsZSB0byBjYXB0aXZlIG5ldHdvcmtzLg0KDQogICAgLS0NCiAg ICBBZGQgbWFpbGluZyBsaXN0DQogICAgQWRkQGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkX187 ISFDUWwzbWNIWDJBIVRLcG56eWYtQVRBcHB2RmxMLTRmckxJaDhRNXJ6YkpkdlhJc0hUS3ZwSlRm Vl91a2R3YzhBZ2pzWVdJNnNubWp1cHBTRHckDQoNCg0K From nobody Wed Jan 15 07:44:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6670120025 for ; Wed, 15 Jan 2020 07:43:52 -0800 (PST) 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, HTML_MESSAGE=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=scramworks.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orjh7RfL7jq5 for ; Wed, 15 Jan 2020 07:43:48 -0800 (PST) Received: from knid.scramworks.net (knid.scramworks.net [IPv6:2a01:4f8:c17:50eb::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1EB120091 for ; Wed, 15 Jan 2020 07:43:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=scramworks.net; s=bofh; h=References:In-Reply-To:To:From:Subject:Message-ID :Date:MIME-Version:Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DYs9lkMPzm5KipHIj9XaT1600qpOUs/YxIhmiXWVbh4=; b=MTu0ZJsgdn4XBF+s997AMqFJrx w5eDMWms5P8PVeM7J6veYDTdOIxJjCo76YJffKfqz8k3lqUaEZ5t52QDZ4J8I98jg0gVEhLFWO8JT D+n1QIiLPuXOO82UGxZyK+apwvtXlI2J6UBWOnGyztKMV+vHFTkoPEnD7TeOIIR7vUD4=; Received: from [90.240.133.23] (helo=[192.168.1.6]) by knid.scramworks.net with esmtpsa (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1irkpb-0000W6-QL for add@ietf.org; Wed, 15 Jan 2020 15:43:44 +0000 Content-Type: multipart/alternative; boundary="----=_NextPart_4249344.873757954056" MIME-Version: 1.0 Date: Wed, 15 Jan 2020 15:42:42 +0000 Message-ID: From: "Robert Mortimer" To: "" In-Reply-To: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> User-Agent: Mailbird/2.7.9.0 X-Mailbird-ID: Mailbird-6b932a67-158f-43e3-b660-bf7399d207b1@scramworks.net X-Spam-Score-SW: -1.0 (-) X-SW-Scan: 9207447d32bfa5765bb6a1125ce59f3b X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 15:43:53 -0000 ------=_NextPart_4249344.873757954056 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 --=C2=A0 Robm 873 =C2=A0 "Ask not what I can do for the stupid,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but what the stupid can do for me" - Grae= me Garden On 15/01/2020 15:15:09, Paul Hoffman wrote: The following paragraph in the proposed charter is impossible to meet for t= he vast majority of use cases that have been discussed on this list: Any mechanisms that specify interactions between clients and servers must provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor. Any mechanism whose understanding of the network and network services comes= from interactions that were not cryptographically authenticated (such as D= HCP and RA) cannot meet those requirements. The presence of that paragraph will basically stop work being done in the W= G once it is chartered. Please strongly consider removing it. Without that = paragraph, the charter seems fine. --Paul Hoffman-- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add ------=_NextPart_4249344.873757954056 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=0A =0A = =0A = =0A =0A = =0A +1

-- 
Robm
873
&nb= sp; "Ask not what I can do for the stupid, 
    &n= bsp;    but what the stupid can do for me" - Graeme Garden
<= /div>
=0A

On 15/01/2020 15:15:09, Paul Hoffman <paul.hoffman@ica= nn.org> wrote:

= The following paragraph in the proposed charter is impossible to meet for t= he vast majority of use cases that have been discussed on this list:=0A
= =0A
Any mechanisms that specify interactions between clients and=0A
s= ervers must provide the security properties expected of IETF=0A
protocol= s, e.g., confidentiality protection, integrity protection,=0A
and authen= tication with strong work factor.=0A
=0A
Any mechanism whose understa= nding of the network and network services comes from interactions that were= not cryptographically authenticated (such as DHCP and RA) cannot meet thos= e requirements.=0A
=0A
The presence of that paragraph will basically = stop work being done in the WG once it is chartered. Please strongly consid= er removing it. Without that paragraph, the charter seems fine.=0A
=0A--Paul Hoffman-- =0A
Add mailing list=0A
Add@ietf.org=0A
https:/= /www.ietf.org/mailman/listinfo/add=0A
=0A = =0A ------=_NextPart_4249344.873757954056-- From nobody Wed Jan 15 07:46:29 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B051200B4 for ; Wed, 15 Jan 2020 07:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIAxcqS1tTi5 for ; Wed, 15 Jan 2020 07:45:24 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100086.outbound.protection.outlook.com [40.107.10.86]) (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 18DD71200E7 for ; Wed, 15 Jan 2020 07:45:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XcLCOtRBosvuU8M7r0DH+n2DRkquMpROYuFB50JJ7XfXeOC3791kLZwF7HLBAh5yG+ivuNIb0rvjzTA59rKDzb2QYAhf3p9GgoiqWinw4vkTJTdl8DrlXP5V/MHSLEqs1je2F2spBNKEtd2IvOVKY44w4/1JUTkIGM/tUJBNh/jle5yZyfVEFpbJGgqR5FosF7OiLRI696gE1JNHUyWGSdota9vDovADIGWSNPcUTsU9wcExAW1T+I8DF1XLlwezaTJTF3cPuGnmWPF4Usn6KbLR23Xk1UejIc+VSVxtHrt05tlkvyfuWy4x3QCWx3MxLCb/s1Z56sc/+d4kmXR6Zw== 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=G9/Th4RSb9XFhSwqEDpSCKgBG1jj6wzyIZalCDVl6Hc=; b=EYjqOAw1w+RWs/Jt5ogx95q84h7CkdmmbUwkHXNTz5tzshY9gwdp3nT0890LRma1BFxmVLqK9Sc5jBaCX7XUn2HmxdT+vTOfhVlxNQFMVFrSS1mmkn3unUv/zuywdaqw/5ufSNHwCEUQqK10KTOXPyhQViSxXzVHw0C92rnd5LY5Esf97DpQ9T1PNvctcI2FTZiYCsMJjo5zVwjPKIuZ2tBenA2c0zyQJHdmXLhUaCLX0yq/rP6iwDd1vx50fdFK/1o5mVRlZtUpjaBRIxj64QPmIS/XQyJj90VUTt+PukFNkVOPUrqz1Affp9vacUm9e6XVCdfwdryStBM1pJhq5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G9/Th4RSb9XFhSwqEDpSCKgBG1jj6wzyIZalCDVl6Hc=; b=CaM8qwg87r+iscmgbPOJTlAWTSLvFOpb4Q7Vb7oHfPpp+ZbyU1G2DaAVZusHMgZK5O7HY6oDoXeP2BsxaOQfhP4lEKYRh/bKSqtVagd0zRnN+oB4LFm/v6fRjj6K3JuM5xvKqqNPRUK/8mkcGus8mcUFfBC+qe7RSipFKoVeAcU= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1262.GBRP265.PROD.OUTLOOK.COM (20.176.146.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 15:45:21 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 15:45:21 +0000 From: Andrew Campling To: Paul Adair , Tommy Pauly , Glenn Deen , ADD Mailing list Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVy7rKNg60w5MoBkW0yHonz9yX8Q== Date: Wed, 15 Jan 2020 15:45:21 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <0E6BAB56-3B54-4032-BD17-30770F242BB1@infoblox.com> In-Reply-To: <0E6BAB56-3B54-4032-BD17-30770F242BB1@infoblox.com> 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=andrew.campling@419.consulting; x-originating-ip: [213.5.92.152] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b4704047-6331-460f-0097-08d799d1ede5 x-ms-traffictypediagnostic: LO2P265MB1262: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39830400003)(376002)(136003)(189003)(199004)(316002)(110136005)(33656002)(81156014)(52536014)(26005)(5660300002)(8676002)(71200400001)(15650500001)(8936002)(81166006)(30864003)(44832011)(186003)(66946007)(53546011)(6506007)(66476007)(2906002)(66446008)(66556008)(86362001)(64756008)(7696005)(76116006)(55016002)(66574012)(966005)(9686003)(508600001)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1262; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rWNHWoGCDbCl8Sp/3vHDnRBCeLK79bNpOQzlhW6Sfxfsh4kZjGyKa2rhmQHdUeikNxldXGx6hN/TagyaN7ikz1mEIhfQ5eJ3k1jTiAG+BlVnkUro0IBNNau26Blb5FzNPiPGTrjbfyZ4rg1aE5J4LmLQ4iosbUZWjY4wpY+VCSIW5GPZKCQ2wyTCgGEeADlftWUR/wWoTfhLaat1/jT5v04sljYx7e2T/xK5nSrMxU2h7CRrlPFct1zs6PZwXGV+i0+lGhxdBEgH0MQhEESPrKCJOmSeXyGNDKxhX1jE57EtzzPKpaHao8kytLYa14KuuyJCN7a9kHekZJPNVSTRSGeatihvf8zwEn0HyahYEgnVZKxiOITWFW057Au+qX3wouiXSxC7bcMj9MZHtNp12WA81tjvWv6MIJg3yHHF66//TOAnzPAUKD/KOmtyP0GUieKsOeBBTcCfJ+90sz3834S+zR8VMxGEkcvglr1kw74pvD/vvdlbNl9GCH9m4T/s x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB05735CDA25DDA3A70364EC15C2370LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: b4704047-6331-460f-0097-08d799d1ede5 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 15:45:21.4027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Co8VUjRe1cxeEDp0qJKs/cdy5+G5h+uOezMUTNcup3CO/Z+COZIqZuoXslWZlOaKb7/wbXmFl0cBC7yvnZAgjEoCUqnJgo0aAwqsjwuTs/U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1262 Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 15:45:29 -0000 --_000_LO2P265MB05735CDA25DDA3A70364EC15C2370LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KQW5kcmV3DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEFk YWlyIDxwYWRhaXJAaW5mb2Jsb3guY29tPg0KU2VudDogMTUgSmFudWFyeSAyMDIwIDEzOjA3DQpU bzogVG9tbXkgUGF1bHkgPHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz47IEFERCBN YWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWRkXSBVcGRhdGVkIGNo YXJ0ZXIgcHJvcG9zYWwgZm9yIEFERA0KDQpJIHN1cHBvcnQgdGhlIGNoYXJ0ZXIgYXMgd3JpdHRl bi4NCg0KUGF1bCBBZGFpcg0KSW5mb2Jsb3gNCg0K77u/T24gMS8xNC8yMCwgNDozOCBQTSwgIkFk ZCBvbiBiZWhhbGYgb2YgVG9tbXkgUGF1bHkiIDxhZGQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgdHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzphZGQtYm91bmNl c0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjB0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMu aWV0Zi5vcmc+PiB3cm90ZToNCg0KICAgIEhpIGFsbCwNCg0KICAgIEkgd2FudGVkIHRvIHNoYXJl IGFuIHVwZGF0ZWQgcHJvcG9zYWwgZm9yIGFuIEFERCBjaGFydGVyLCBiYXNlZCBvbiB0aGUgZmVl ZGJhY2sgYW5kIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgaW4gdGhlIHBhc3Qgc2V2ZXJhbCB3ZWVr cy4NCg0KICAgIFRoaXMgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFsIHByb3Bvc2FsIHRoYXQgd2Fz IHNlbnQgaW4gRGVjZW1iZXIsIHRha2luZyBpbnRvIGFjY291bnQgdmFyaW91cyBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMuIEdsZW5uIERlZW4sIEFuZHJldyBDYW1wbGluZywgYW5kIEkgd29ya2Vk IG9uIHRoaXMgcmV2aXNpb24gdG9nZXRoZXIgYW5kIGNhbWUgdG8gY29uc2Vuc3VzIG9uIGl0cyBj b250ZW50cy4NCg0KICAgIFRob3VnaHRzIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZSBhcyBhbHdh eXMhDQoNCiAgICAoTm90ZSB0aGF0IHRoZSBwcm9wb3NlZCBuYW1lIG9mIHRoZSBncm91cCB3YXMg bm90IGNoYW5nZWQsIGFuZCBpcyBlbnRpcmVseSBvcGVuIHRvIGJpa2VzaGVkZGluZy4gTmFtaW5n IGlzIGhhcmQhKQ0KDQogICAgQmVzdCwNCiAgICBUb21teQ0KDQoNCg0KICAgIEFkYXB0aXZlIERO UyBEaXNjb3ZlcnkgKEFERCkNCiAgICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCiAgICBQcm9wb3NlZCBXb3JraW5nIEdyb3VwIENoYXJ0ZXINCg0KICAgIFNlbmRpbmcgRE5T IG1lc3NhZ2VzIG92ZXIgZW5jcnlwdGVkIHRyYW5zcG9ydHMsIGFzIGRlZmluZWQgaW4gRE5TIG92 ZXINCiAgICBUTFMgKERvVCkgW1JGQyA3ODU4XSBhbmQgRE5TIG92ZXIgSFRUUFMgKERvSCkgW1JG QyA4NDg0XSwgcHJvdmlkZXMNCiAgICBiZW5lZml0cyB0byB0aGUgc2VjdXJpdHkgYW5kIHByaXZh Y3kgb2YgRE5TIGRhdGEuIENsaWVudHMsIHN1Y2ggYXMNCiAgICBhcHBsaWNhdGlvbnMgYW5kIGhv c3Qgb3BlcmF0aW5nIHN5c3RlbXMsIGhhdmUgc3RhcnRlZCBhZG9wdGluZyB0aGVzZQ0KICAgIHBy b3RvY29scyB0byBwcm92aWRlIHRoZXNlIHVzZXIgYmVuZWZpdHMuDQoNCiAgICBUaGlzIHdvcmtp bmcgZ3JvdXAgd2lsbCBmb2N1cyBvbiBkaXNjb3ZlcnkgYW5kIHNlbGVjdGlvbiBvZiBETlMgcmVz b2x2ZXJzDQogICAgYnkgRE5TIGNsaWVudHMgaW4gYSB2YXJpZXR5IG9mIG5ldHdvcmtpbmcgZW52 aXJvbm1lbnRzLCBpbmNsdWRpbmcgcHVibGljDQogICAgbmV0d29ya3MsIHByaXZhdGUgbmV0d29y a3MsIGFuZCBWUE5zOyBzdXBwb3J0aW5nIGJvdGggZW5jcnlwdGVkIGFuZA0KICAgIHVuZW5jcnlw dGVkIHJlc29sdmVycy4NCg0KICAgIENsaWVudHMgYWRvcHRpbmcgZW5jcnlwdGVkIEROUyBwcm90 b2NvbHMgbmVlZCB0byBkZXRlcm1pbmUgd2hpY2ggRE5TDQogICAgc2VydmVycyBzdXBwb3J0IGVu Y3J5cHRlZCB0cmFuc3BvcnRzLCBhbmQgd2hpY2ggc2VydmVyIHRvIHVzZSBmb3Igc3BlY2lmaWMN CiAgICBxdWVyaWVzIGlmIG11bHRpcGxlIHNlcnZlcnMgYXJlIGF2YWlsYWJsZS4gVGhlc2UgZGVj aXNpb25zIGNhbiB2YXJ5IGJhc2VkDQogICAgb24gdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQsIGFu ZCBhbHNvIGJhc2VkIG9uIHRoZSBjb250ZW50IGFuZCBwdXJwb3NlIG9mDQogICAgdGhlIGNsaWVu dCBxdWVyaWVzLg0KDQogICAgTmV0d29yayBvcGVyYXRvcnMgdGhhdCBzdGFydCBvZmZlcmluZyBE TlMgZW5jcnlwdGlvbiBvbiB0aGVpciBzZXJ2ZXJzIGFsc28NCiAgICBuZWVkIGEgd2F5IHRvIGlu ZGljYXRlIHRoaXMgc3VwcG9ydCB0byBjbGllbnRzLiBDb21tdW5pY2F0aW5nIGluZm9ybWF0aW9u DQogICAgYWJvdXQgcmVzb2x2ZXIgY29uZmlndXJhdGlvbiBhbmQgYmVoYXZpb3IgYWxsb3dzIGNs aWVudHMgdG8gbWFrZSBtb3JlDQogICAgaW5mb3JtZWQgZGVjaXNpb25zIGFib3V0IHdoaWNoIERO UyBzZXJ2ZXJzIHRvIHVzZS4gRm9yIGV4YW1wbGUsIGEgcmVzb2x2ZXINCiAgICBtYXkgYmUgYWJs ZSB0byByZXNvbHZlIHByaXZhdGUgb3IgbG9jYWwgbmFtZXMgYXMgYSBzcGxpdCBETlMgc2VydmVy Lg0KDQogICAgVGhlIEFkYXB0aXZlIEROUyBEaXNjb3ZlcnkgKEFERCkgd29ya2luZyBncm91cCB3 aWxsIHdvcmsgb24gdGhlIGZvbGxvd2luZw0KICAgIGRlbGl2ZXJhYmxlczoNCg0KICAgIC0gZGVm aW5lIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGNsaWVudHMgdG8gZGlzY292ZXIgRE5TIHJlc29s dmVycywNCiAgICBpbmNsdWRpbmcgZW5jcnlwdGVkIEROUyBzZXJ2ZXJzLCB0aGF0IGFyZSBhdmFp bGFibGUgdG8gdGhlIGNsaWVudA0KICAgIGVpdGhlciBvbiB0aGUgcHVibGljIEludGVybmV0IG9y IG9uIHByaXZhdGUgb3IgbG9jYWwgbmV0d29ya3M7DQoNCiAgICAtIGRlZmluZSBhIG1lY2hhbmlz bSB0aGF0IGFsbG93cyBjb21tdW5pY2F0aW9uIG9mIEROUyByZXNvbHZlcg0KICAgIGluZm9ybWF0 aW9uIHRvIGNsaWVudHMgZm9yIHVzZSBpbiBzZWxlY3Rpb24gZGVjaXNpb25zOw0KDQogICAgLSBk ZXZlbG9wIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgaG93IGNsaWVu dA0KICAgIGFwcGxpY2F0aW9ucyBhbmQgc3lzdGVtcyBjYW4gbWFuYWdlIHNlbGVjdGlvbiBvZiBE TlMgcmVzb2x2ZXJzDQogICAgaW4gdmFyaW91cyBuZXR3b3JrIGVudmlyb25tZW50cyBhbmQgdXNl IGNhc2VzLg0KDQogICAgQW55IG1lY2hhbmlzbXMgdGhhdCBzcGVjaWZ5IGludGVyYWN0aW9ucyBi ZXR3ZWVuIGNsaWVudHMgYW5kDQogICAgc2VydmVycyBtdXN0IHByb3ZpZGUgdGhlIHNlY3VyaXR5 IHByb3BlcnRpZXMgZXhwZWN0ZWQgb2YgSUVURg0KICAgIHByb3RvY29scywgZS5nLiwgY29uZmlk ZW50aWFsaXR5IHByb3RlY3Rpb24sIGludGVncml0eSBwcm90ZWN0aW9uLA0KICAgIGFuZCBhdXRo ZW50aWNhdGlvbiB3aXRoIHN0cm9uZyB3b3JrIGZhY3Rvci4NCg0KICAgIFRoaXMgd29ya2luZyBn cm91cCB3aWxsIGNvb3JkaW5hdGUgd2l0aCBkbnNvcCwgZG9oLCBhbmQgZHByaXZlIGZvciBhbnkN CiAgICBjaGFuZ2VzIHJlcXVpcmVkIGluIEROUyBwcm90b2NvbHMuIEl0IHdpbGwgYWxzbyB3b3Jr IHdpdGggY2FwcG9ydCB0bw0KICAgIGVuc3VyZSB0aGF0IHNvbHV0aW9ucyBhcmUgYXBwbGljYWJs ZSB0byBjYXB0aXZlIG5ldHdvcmtzLg0KDQogICAgLS0NCiAgICBBZGQgbWFpbGluZyBsaXN0DQog ICAgQWRkQGlldGYub3JnPG1haWx0bzpBZGRAaWV0Zi5vcmc+DQogICAgaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkX187 ISFKWXNnVFJBZzZaUSFZQVlXcHFJei01bW5WS0ZQMXVvbWFIblpxYWFQZU03amdfdDNiMkpFYjFS R0tJTERNdGx0djFlRDY4VkRoM1kkDQoNCg0KDQo= --_000_LO2P265MB05735CDA25DDA3A70364EC15C2370LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQ7Ij4NCjxkaXY+JiM0MzsxPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj48Yj5BbmRyZXc8L2I+PC9kaXY+DQo8YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjwv YT4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KDQpGcm9tOiBQYXVsIEFkYWlyICZsdDtwYWRhaXJAaW5mb2Jsb3guY29tJmd0OyA8YnI+DQoN ClNlbnQ6IDE1IEphbnVhcnkgMjAyMCAxMzowNzxicj4NCg0KVG86IFRvbW15IFBhdWx5ICZsdDt0 cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBBREQgTWFpbGluZyBsaXN0ICZs dDthZGRAaWV0Zi5vcmcmZ3Q7PGJyPg0KDQpTdWJqZWN0OiBSZTogW0FkZF0gVXBkYXRlZCBjaGFy dGVyIHByb3Bvc2FsIGZvciBBREQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkkgc3Vw cG9ydCB0aGUgY2hhcnRlciBhcyB3cml0dGVuLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+UGF1bCBBZGFpcjwvZGl2Pg0KPGRpdj5JbmZvYmxveDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+77u/T24gMS8xNC8yMCwgNDozOCBQTSwgJnF1b3Q7QWRkIG9uIGJlaGFsZiBvZiBU b21teSBQYXVseSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiB0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmciPmFkZC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0cGF1bHk9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZu YnNwOyZuYnNwOyBIaSBhbGwsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsm bmJzcDsmbmJzcDsgSSB3YW50ZWQgdG8gc2hhcmUgYW4gdXBkYXRlZCBwcm9wb3NhbCBmb3IgYW4g QUREIGNoYXJ0ZXIsIGJhc2VkIG9uIHRoZSBmZWVkYmFjayBhbmQgZGlzY3Vzc2lvbiBvbiB0aGUg bGlzdCBpbiB0aGUgcGFzdCBzZXZlcmFsIHdlZWtzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFsIHBy b3Bvc2FsIHRoYXQgd2FzIHNlbnQgaW4gRGVjZW1iZXIsIHRha2luZyBpbnRvIGFjY291bnQgdmFy aW91cyBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIEdsZW5uIERlZW4sIEFuZHJldyBDYW1wbGlu ZywgYW5kIEkgd29ya2VkIG9uIHRoaXMgcmV2aXNpb24gdG9nZXRoZXIgYW5kIGNhbWUgdG8gY29u c2Vuc3VzIG9uIGl0cyBjb250ZW50cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyBUaG91Z2h0cyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUgYXMgYWx3 YXlzITwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IChO b3RlIHRoYXQgdGhlIHByb3Bvc2VkIG5hbWUgb2YgdGhlIGdyb3VwIHdhcyBub3QgY2hhbmdlZCwg YW5kIGlzIGVudGlyZWx5IG9wZW4gdG8gYmlrZXNoZWRkaW5nLiBOYW1pbmcgaXMgaGFyZCEpPC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgQmVzdCw8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvbW15PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpPC9kaXY+DQo8ZGl2PiZuYnNwOyZu YnNwOyZuYnNwOyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2Rpdj4NCjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3Bvc2VkIFdvcmtpbmcgR3JvdXAgQ2hhcnRlcjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbmRpbmcgRE5T IG1lc3NhZ2VzIG92ZXIgZW5jcnlwdGVkIHRyYW5zcG9ydHMsIGFzIGRlZmluZWQgaW4gRE5TIG92 ZXI8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRMUyAoRG9UKSBbUkZDIDc4NThdIGFu ZCBETlMgb3ZlciBIVFRQUyAoRG9IKSBbUkZDIDg0ODRdLCBwcm92aWRlczwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsgYmVuZWZpdHMgdG8gdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IG9m IEROUyBkYXRhLiBDbGllbnRzLCBzdWNoIGFzPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyBhcHBsaWNhdGlvbnMgYW5kIGhvc3Qgb3BlcmF0aW5nIHN5c3RlbXMsIGhhdmUgc3RhcnRlZCBh ZG9wdGluZyB0aGVzZTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgcHJvdG9jb2xzIHRv IHByb3ZpZGUgdGhlc2UgdXNlciBiZW5lZml0cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBmb2N1cyBvbiBk aXNjb3ZlcnkgYW5kIHNlbGVjdGlvbiBvZiBETlMgcmVzb2x2ZXJzPC9kaXY+DQo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyBieSBETlMgY2xpZW50cyBpbiBhIHZhcmlldHkgb2YgbmV0d29ya2luZyBl bnZpcm9ubWVudHMsIGluY2x1ZGluZyBwdWJsaWM8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7IG5ldHdvcmtzLCBwcml2YXRlIG5ldHdvcmtzLCBhbmQgVlBOczsgc3VwcG9ydGluZyBib3Ro IGVuY3J5cHRlZCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVuZW5jcnlwdGVk IHJlc29sdmVycy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyBDbGllbnRzIGFkb3B0aW5nIGVuY3J5cHRlZCBETlMgcHJvdG9jb2xzIG5lZWQgdG8gZGV0 ZXJtaW5lIHdoaWNoIEROUzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgc2VydmVycyBz dXBwb3J0IGVuY3J5cHRlZCB0cmFuc3BvcnRzLCBhbmQgd2hpY2ggc2VydmVyIHRvIHVzZSBmb3Ig c3BlY2lmaWM8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHF1ZXJpZXMgaWYgbXVsdGlw bGUgc2VydmVycyBhcmUgYXZhaWxhYmxlLiBUaGVzZSBkZWNpc2lvbnMgY2FuIHZhcnkgYmFzZWQ8 L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9uIHRoZSBuZXR3b3JrIGVudmlyb25tZW50 LCBhbmQgYWxzbyBiYXNlZCBvbiB0aGUgY29udGVudCBhbmQgcHVycG9zZSBvZjwvZGl2Pg0KPGRp dj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGNsaWVudCBxdWVyaWVzLjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5ldHdvcmsgb3BlcmF0b3JzIHRoYXQg c3RhcnQgb2ZmZXJpbmcgRE5TIGVuY3J5cHRpb24gb24gdGhlaXIgc2VydmVycyBhbHNvPC9kaXY+ DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBuZWVkIGEgd2F5IHRvIGluZGljYXRlIHRoaXMgc3Vw cG9ydCB0byBjbGllbnRzLiBDb21tdW5pY2F0aW5nIGluZm9ybWF0aW9uPC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyBhYm91dCByZXNvbHZlciBjb25maWd1cmF0aW9uIGFuZCBiZWhhdmlv ciBhbGxvd3MgY2xpZW50cyB0byBtYWtlIG1vcmU8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i c3A7IGluZm9ybWVkIGRlY2lzaW9ucyBhYm91dCB3aGljaCBETlMgc2VydmVycyB0byB1c2UuIEZv ciBleGFtcGxlLCBhIHJlc29sdmVyPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBtYXkg YmUgYWJsZSB0byByZXNvbHZlIHByaXZhdGUgb3IgbG9jYWwgbmFtZXMgYXMgYSBzcGxpdCBETlMg c2VydmVyLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZSBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3Jr IG9uIHRoZSBmb2xsb3dpbmc8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbGl2ZXJh Ymxlczo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAt IGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBjbGllbnRzIHRvIGRpc2NvdmVyIEROUyBy ZXNvbHZlcnMsPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBpbmNsdWRpbmcgZW5jcnlw dGVkIEROUyBzZXJ2ZXJzLCB0aGF0IGFyZSBhdmFpbGFibGUgdG8gdGhlIGNsaWVudDwvZGl2Pg0K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgZWl0aGVyIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQgb3Ig b24gcHJpdmF0ZSBvciBsb2NhbCBuZXR3b3Jrczs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAtIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBj b21tdW5pY2F0aW9uIG9mIEROUyByZXNvbHZlcjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJz cDsgaW5mb3JtYXRpb24gdG8gY2xpZW50cyBmb3IgdXNlIGluIHNlbGVjdGlvbiBkZWNpc2lvbnM7 PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgLSBkZXZl bG9wIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgaG93IGNsaWVudDwv ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zIGFuZCBzeXN0ZW1zIGNh biBtYW5hZ2Ugc2VsZWN0aW9uIG9mIEROUyByZXNvbHZlcnM8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluIHZhcmlvdXMgbmV0d29yayBlbnZpcm9ubWVudHMgYW5kIHVzZSBjYXNlcy48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBBbnkgbWVj aGFuaXNtcyB0aGF0IHNwZWNpZnkgaW50ZXJhY3Rpb25zIGJldHdlZW4gY2xpZW50cyBhbmQ8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZlcnMgbXVzdCBwcm92aWRlIHRoZSBzZWN1 cml0eSBwcm9wZXJ0aWVzIGV4cGVjdGVkIG9mIElFVEY8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHByb3RvY29scywgZS5nLiwgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24sIGludGVn cml0eSBwcm90ZWN0aW9uLDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgYW5kIGF1dGhl bnRpY2F0aW9uIHdpdGggc3Ryb25nIHdvcmsgZmFjdG9yLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGNvb3Jk aW5hdGUgd2l0aCBkbnNvcCwgZG9oLCBhbmQgZHByaXZlIGZvciBhbnk8L2Rpdj4NCjxkaXY+Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZXMgcmVxdWlyZWQgaW4gRE5TIHByb3RvY29scy4gSXQgd2ls bCBhbHNvIHdvcmsgd2l0aCBjYXBwb3J0IHRvPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyBlbnN1cmUgdGhhdCBzb2x1dGlvbnMgYXJlIGFwcGxpY2FibGUgdG8gY2FwdGl2ZSBuZXR3b3Jr cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyAtLSA8 L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFkZCBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxk aXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpBZGRAaWV0Zi5vcmciPkFkZEBp ZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FkZF9fOyEhSllzZ1RSQWc2WlEhWUFZV3BxSXotNW1uVktGUDF1b21hSG5acWFhUGVNN2pn X3QzYjJKRWIxUkdLSUxETXRsdHYxZUQ2OFZEaDNZJCI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkX187ISFKWXNnVFJB ZzZaUSFZQVlXcHFJei01bW5WS0ZQMXVvbWFIblpxYWFQZU03amdfdDNiMkpFYjFSR0tJTERNdGx0 djFlRDY4VkRoM1kkPC9hPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_LO2P265MB05735CDA25DDA3A70364EC15C2370LO2P265MB0573GBRP_-- From nobody Wed Jan 15 07:48:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB97120850 for ; Wed, 15 Jan 2020 07:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 yXH8wp06rk4Z for ; Wed, 15 Jan 2020 07:47:45 -0800 (PST) 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 2CE3B12085F for ; Wed, 15 Jan 2020 07:46:57 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id i13so16145252qtr.3 for ; Wed, 15 Jan 2020 07:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bgEZ0Z2J8SbjGxUVR5+XqXvfRbmFvWuSfnL38wn0UhE=; b=xUG2aGO1HiOpqS6OfXFiJ5eQKj1cKC7Fs2wfxndLJdLnW7NCmpMi7MaslHH+3FC9a8 XisX70Pc3/4KJ5tQ5KYfCaMr+MOb//O/jZPdy8SM57C/jUKWg30UDwqoySdJbN+AOQ+R ccAcCRHNs7cX5wuZwMgNMKRkYI0AYEoh4ty5/dQtlHV/dYU9d0jCnWqZgpUJyUBM6qTG ALZt4GxWRB10k2hgcJgmSez/jmekNdAF36tQ4lkmSrVTzaJZkwKUS4g0BV8PmfAIN9Ts fmVAZARZsFvsk/XlIXSnkcnWR6n8pgWCUxEmT8I06n5lx1wq6w4uMXT3UxZzZSdwHe14 5VOg== 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=bgEZ0Z2J8SbjGxUVR5+XqXvfRbmFvWuSfnL38wn0UhE=; b=eUQ2jBywa00uEGtkBf677I8G/T0Wb+NemS4amBEqf1GKMe8W9HBN50rDmjomBVN0zN 8DYbZpSWjUJj5BALRUmVYGDn0slR1e7sN91tNySFcifF0+Rh6BGynWXorJ2maV+t1Ew4 z1JSWFDFtgllggqCnYJ1dUlrFlKuh+N7ytEBRPlmJJSWLOw6gvwRoh9xZVKE0/of0K7i OchPjY7mwzzudHUpzOFCEP27VKDhCP2ZB9z1o9OkAZGQskMfbCffSnSdrUcSeTmmJUgY x8r9OQ4mcL5WwOMnAqFCvehL/F2bfIpQ9UJi6J0aBeW+42aNcengl7+3H6rZISMuSHR9 UwpQ== X-Gm-Message-State: APjAAAUHVVuyb4WG4D/rtyQauPPituUlihGZ7bVZSff7K6iLBDjKzMWQ 1htwATdjK4GPU/z0jD1dQ63kTDCek4QqIw== X-Google-Smtp-Source: APXvYqyfCe1VdOrSdHlBYShhqGi9WOQsUDdxQfH5KiGumzYC+18ARJkZBJXQ79KyXYE0rv/u+zifxg== X-Received: by 2002:ac8:c4f:: with SMTP id l15mr4109024qti.177.1579103216258; Wed, 15 Jan 2020 07:46:56 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id u4sm8467221qkh.59.2020.01.15.07.46.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 07:46:55 -0800 (PST) From: Ted Lemon Message-Id: <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_22EDCF39-6333-4DC3-9F8E-9D67BA5941CF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 15 Jan 2020 10:46:54 -0500 In-Reply-To: Cc: Tommy Pauly , ADD Mailing list To: Paul Hoffman References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 15:47:54 -0000 --Apple-Mail=_22EDCF39-6333-4DC3-9F8E-9D67BA5941CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 10:13 AM, Paul Hoffman = wrote: > Any mechanisms that specify interactions between clients and > servers must provide the security properties expected of IETF > protocols, e.g., confidentiality protection, integrity protection, > and authentication with strong work factor. >=20 > Any mechanism whose understanding of the network and network services = comes from interactions that were not cryptographically authenticated = (such as DHCP and RA) cannot meet those requirements. Rather than just deleting this text, which I agree is probably not what = we want, how about fixing it? Any specification must include a clear and thorough discussion of the = privacy and security implications of using the method or methods it = describes. Methods where a mechanism that cannot be cryptographically = validated for integrity or which do not provide a cryptographically = validatable trust establishment mechanism will clearly describe the use = case(s) in which such an override is thought to be needed, should have a = clear applicability statement limiting the scope of the specification to = those use case(s), and should clearly describe the risks and benefits of = such a choice. The first sentence is unnecessary since this is what is expected in the = IETF anyway, but it sets the stage for the sentences that follow. The = point of this is not to prevent the WG specifying methods that can=E2=80=99= t be cryptographically validated for integrity and/or trust, but rather = to make it clear that such a specification would not be in charter if it = didn=E2=80=99t meet the stated requirements. --Apple-Mail=_22EDCF39-6333-4DC3-9F8E-9D67BA5941CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 15, 2020, at 10:13 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Any mechanisms that specify interactions between clients = and
servers must = provide the security properties expected of IETF
protocols, = e.g., confidentiality protection, integrity protection,
and = authentication with strong work factor.

Any mechanism whose understanding of the network and network = services comes from interactions that were not cryptographically = authenticated (such as DHCP and RA) cannot meet those = requirements.

Rather than just deleting this text, which I agree is = probably not what we want, how about fixing it?

Any specification must include a clear = and thorough discussion of the privacy and security implications of = using the method or methods it describes.  Methods where a = mechanism that cannot be cryptographically validated for integrity or = which do not provide a cryptographically validatable trust establishment = mechanism will clearly describe the use case(s) in which such an = override is thought to be needed, should have a clear applicability = statement limiting the scope of the specification to those use case(s), = and should clearly describe the risks and benefits of such a = choice.

The = first sentence is unnecessary since this is what is expected in the IETF = anyway, but it sets the stage for the sentences that follow.   The = point of this is not to prevent the WG specifying methods that can=E2=80=99= t be cryptographically validated for integrity and/or trust, but rather = to make it clear that such a specification would not be in charter if it = didn=E2=80=99t meet the stated requirements.

= --Apple-Mail=_22EDCF39-6333-4DC3-9F8E-9D67BA5941CF-- From nobody Wed Jan 15 07:54:55 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16B5120832 for ; Wed, 15 Jan 2020 07:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 TcT7nsuAg00Q for ; Wed, 15 Jan 2020 07:54:11 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC121200E0 for ; Wed, 15 Jan 2020 07:54:11 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 24BC9116D9D; Wed, 15 Jan 2020 10:54:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24095.13730.124469.943932@gro.dd.org> Date: Wed, 15 Jan 2020 10:54:10 -0500 From: Dave Lawrence To: ADD Mailing list In-Reply-To: <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 15:54:18 -0000 Ted Lemon writes: > Rather than just deleting this text, which I agree is probably not > what we want, how about fixing it? That's where I am on this. I like the proposal as a whole and just think this little bit on the security properties needs tweaking. I've got to run at the moment though and apologize for not having a concrete proposal for the tweak. From nobody Wed Jan 15 08:10:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCFC12085B for ; Wed, 15 Jan 2020 08:09:51 -0800 (PST) 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 5HmhgMJ92liV for ; Wed, 15 Jan 2020 08:09:49 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 95963120839 for ; Wed, 15 Jan 2020 08:09:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AEEC86601AE; Wed, 15 Jan 2020 18:09:47 +0200 (EET) 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 3c7X2AO0Apsk; Wed, 15 Jan 2020 18:09:41 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 510966600DE; Wed, 15 Jan 2020 18:09:41 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Date: Wed, 15 Jan 2020 18:09:40 +0200 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <76785894-9B79-4EA7-83DA-22A589D9FDBA@piuha.net> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 16:09:52 -0000 Thanks for this, Tommy. I support this charter, and I think it is important work. I have two = further points to make, on areas where we may wish to make changes (but = I can live with current charter). 1. I think the third paragraph would benefit from an observation that = the choices have implications. I=E2=80=99d suggest this tweak: OLD: These decisions can vary based on the network environment, and also = based on the content and purpose of the client queries. NEW: These decisions can vary based on the network environment, and also = based on the content and purpose of the client queries. The decisions = may have implications on reachability, privacy, and so on. 2. As noted, the paragraph on =E2=80=9Cany mechanisms=E2=80=9D has some = issues, and could be either removed (can live with that) or improved = (can live with that as well, as long as the improvement process = terminates=E2=80=A6) Jari From nobody Wed Jan 15 08:19:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6A112085B for ; Wed, 15 Jan 2020 08:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 g_qSf6J8I_lN for ; Wed, 15 Jan 2020 08:18:16 -0800 (PST) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 02A2A120841 for ; Wed, 15 Jan 2020 08:18:15 -0800 (PST) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa3.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id 00FGIENO008264 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 15 Jan 2020 16:18:14 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Jan 2020 08:18:12 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Wed, 15 Jan 2020 08:18:12 -0800 From: Paul Hoffman To: ADD Mailing list Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy7sS3dTn6q33TECqcNmmmuiki6fsbWiA Date: Wed, 15 Jan 2020 16:18:11 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> In-Reply-To: <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_6B996BF8-B8BE-4042-BB68-1CCE52572853"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-15_02:, , signatures=0 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 16:18:21 -0000 --Apple-Mail=_6B996BF8-B8BE-4042-BB68-1CCE52572853 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 7:46 AM, Ted Lemon wrote: >=20 > On Jan 15, 2020, at 10:13 AM, Paul Hoffman = wrote: >> Any mechanisms that specify interactions between clients and >> servers must provide the security properties expected of IETF >> protocols, e.g., confidentiality protection, integrity protection, >> and authentication with strong work factor. >>=20 >> Any mechanism whose understanding of the network and network services = comes from interactions that were not cryptographically authenticated = (such as DHCP and RA) cannot meet those requirements. >=20 > Rather than just deleting this text, which I agree is probably not = what we want, how about fixing it? Because I don't think we can get consensus on the fixed wording *for the = charter*. I would prefer to have the consensus discussions for the = documents themselves. > Any specification must include a clear and thorough discussion of the = privacy and security implications of using the method or methods it = describes. Methods where a mechanism that cannot be cryptographically = validated for integrity or which do not provide a cryptographically = validatable trust establishment mechanism will clearly describe the use = case(s) in which such an override is thought to be needed, should have a = clear applicability statement limiting the scope of the specification to = those use case(s), and should clearly describe the risks and benefits of = such a choice. The first sentence is well-intentioned but does not usually lead to = useful text in documents. The second sentence assumes that there are = methods that can be cryptographically validated: as I said above, I do = not believe they exist. > The first sentence is unnecessary since this is what is expected in = the IETF anyway, Fully agree. > but it sets the stage for the sentences that follow. ...and thus is unnecessary. > The point of this is not to prevent the WG specifying methods that = can=E2=80=99t be cryptographically validated for integrity and/or trust, = but rather to make it clear that such a specification would not be in = charter if it didn=E2=80=99t meet the stated requirements. Again, we disagree here because I (and others) don't agree that such = methods exist. --Paul Hoffman= --Apple-Mail=_6B996BF8-B8BE-4042-BB68-1CCE52572853 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMTE1MTYxODExWjAvBgkqhkiG9w0BCQQxIgQg9jqjPv2AZZXyAfZxnQMbkhxHZCUj r4s87xyWCk13p6cwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAEZjH694i3yiX6fcr8+hrfvoiSjohma91xNcBHrsVe1z YPPi6ZzRCmfGKbo8s44zzmJm31ZiBtxw0V9zbOxKtjejx7ZlGheHhEkczeRK50/n0USabWnWGD2k k4n/LjcPtZacJPRBTl2JGC+nWi8d8YE2f/81B+01L/GMNgm6lH5jIOS/q13QAYpE/7YT/MjUmwWI 0I2deNpyUzFcpFEgAgfOK3x7pe9EZLnmHsCDamZv0D/Rne9fI7XUh72ql8t4j1N/0rR33pMAiXmn jG6eiHZtLcQRwP20sKzBk49eYzxqXwT53tNv7nh0qa4SSVHt1Qy2p6XnySGB7xIr4iRroyAAAAAA AAA= --Apple-Mail=_6B996BF8-B8BE-4042-BB68-1CCE52572853-- From nobody Wed Jan 15 08:19:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC319120839 for ; Wed, 15 Jan 2020 08:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 U9PzDy65s7K3 for ; Wed, 15 Jan 2020 08:18:48 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 19F2112085B for ; Wed, 15 Jan 2020 08:18:48 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id t129so16133778qke.10 for ; Wed, 15 Jan 2020 08:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1iOxFOoGAwLKYR7a0WgdLitoTfbTOwT3h5wbL2vg/VI=; b=fSpQRbd1cJSrh5+F34B2dquEwpFu6GEWFE/LLPeDZT0IQMxkLjrOBY8xqp5UuNaECl fSkGidj2jkz5BYWDAgwGtNRPVLvgufo2F9BtyxAALxw9kmpkgJ5RmIyl/VyUlugJ43VG pMm0RQYOLOxfQc09wSx7cGAJZWdn7/EsKPAv4HOplCUPuTnXSmYMUqNGy8v+I7oP16h2 /LtqU/ixEbAChxz1FS9SeL/7+SQRz1VgRZdQ7bqSMSfa0IUp2oIJa/7/mZq3zPuFhvC0 mTM8XPUwyROZjbqDHzvCDHIQyG3EdXgFM0pK2gqihgw+cAr27KRMoa1CBp16sC0Tps2x +ttw== 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=1iOxFOoGAwLKYR7a0WgdLitoTfbTOwT3h5wbL2vg/VI=; b=kqGabYrWQ3D8losVWleqVVL8M2tdeQq/M47Hp8L8a1dJWbPD9OG//Q/3oQa1hHMSBD 64FK5JxqDJxe2QXTmi0ugPiMK7P7Fekz2Zt2VLJ2o1U2bKXU63k0fsusqmSuvGaFeyt3 qF+8F1nwdr22HqQAOZ3EkyNV8ALviW369hDl3H8bo0H1H8BtgbCeoFsMUKBNJDco55F2 jUt/4oItUObDeM3d+YuIlpJTguoUSGFCfASsbu/JryeqGyIaKopRw2UZTXueg0So39kJ CfM0bnkgU6XaqcUYHFqq9BwuE8iYJJqj23Mkn5xX82lbIbRN5l/4wBMQ2a725oESlWmB cTNg== X-Gm-Message-State: APjAAAU6s+tXST5Y+vvzqUqBQUVEurMm3inw5iM2v+drFMqzvLySYAyg QRRIgbCu43Ylkfw79/ATTvWpvKIIswGfHg== X-Google-Smtp-Source: APXvYqzx7IqmaNB6M2t0q9ZsLlT+SOS0vmPU9A7+/6fzDRSBhlrT9skCciHzzAU++uCVUjvZZd2uUw== X-Received: by 2002:a37:c244:: with SMTP id j4mr26633680qkm.433.1579105127229; Wed, 15 Jan 2020 08:18:47 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id c13sm8624524qko.87.2020.01.15.08.18.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 08:18:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) From: Ted Lemon In-Reply-To: <24095.13730.124469.943932@gro.dd.org> Date: Wed, 15 Jan 2020 11:18:43 -0500 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 16:18:55 -0000 On Jan 15, 2020, at 10:54 AM, Dave Lawrence wrote: > That's where I am on this. I like the proposal as a whole and just > think this little bit on the security properties needs tweaking. I've > got to run at the moment though and apologize for not having a > concrete proposal for the tweak. In case it=E2=80=99s not obvious, this is what I was proposing for a = tweak: Any specification must include a clear and thorough discussion of the = privacy and security implications of using the method or methods it = describes. Methods where a mechanism that cannot be cryptographically = validated for integrity or which do not provide a cryptographically = validatable trust establishment mechanism will clearly describe the use = case(s) in which such an override is thought to be needed, should have a = clear applicability statement limiting the scope of the specification to = those use case(s), and should clearly describe the risks and benefits of = such a choice. From nobody Wed Jan 15 08:30:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05269120841 for ; Wed, 15 Jan 2020 08:29:36 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 dTg9U33Thsr8 for ; Wed, 15 Jan 2020 08:29:32 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130071.outbound.protection.outlook.com [40.107.13.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 E3B91120839 for ; Wed, 15 Jan 2020 08:29:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kJ3s8mIZb5Ksx4BQy6ZQBDMbyxbt2DGmy3JlqeNevuSf7+HmiZskv9ZZNRUJ/YSQI6t//tKawAgWYNt8E16VFxic92JYat8MnxBf6yqM2A9cigITHJtg5w4hwT/Tx9y+pPTfVnlrMoYLw1LPP4028qTE0Qw4/sObhkNUWYqnJZrOpbTdFKKA6NYf6yf7eGnZdM612S0FQXc5oL8BQF2llwAoKkG221cKonOihHnRK6DCB3uEBhAPa0PyZKdm9EKs08OKxBkWipGWYgH7zNE2Iq2W9lSmTWKPBWm24c0zi6JDwIgnCY2EoeiCnaSMlBAzghpyweIBWVvRwTgyLTvAQA== 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=KH4HcB4HlZ8wjS9svRErkykD1v/WagMIBGVWcfb78qQ=; b=iAsLaHGkDz35tdPPLOCdbi66yMBzZFyY0DvZK9W/DvQ/SqIUEqr/X3AqrERmAzQh8yv5NaFCWU5w3bywCRjtanqJg3FGJdLT/29tj2kKXO7zXThzviINJKbzgMLxUoYqTQDRVqn4bTD2T/eOjwN3oYRnlrBUE5pU7ng/GbX8JzcHf/1RqDEDViDdSonegQgoYi7UuMuj8IKiwmdfWJl/42Mwo6m0DDp568R5MuDsfpFmct/YZbOtgD49bBE8LK30FSSA14532R/hUIFlV+6LbrOQ4gLinYlzVKCncYlypYUT/f2fi+5RLxSeqSLOpa0c8Zak7BaiSJ9pYGF4k3sFCA== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KH4HcB4HlZ8wjS9svRErkykD1v/WagMIBGVWcfb78qQ=; b=JIzx+6YKGL43YqneFuXe4JA85IcZxfkddakGu5sIxDSqQwr8JZs/sCITb2odIcDa835Z0638KAjIjUn5uR+NdddsUcI2akCvcDRCoXJHHajWuEb1vEvBk5G886eLPfnMAtn0znPmWypKd7SPqDceaPvHKtE6N081EoCU6SAfDSA= Received: from DB8PR06MB6521.eurprd06.prod.outlook.com (52.135.60.13) by DB8PR06MB6474.eurprd06.prod.outlook.com (52.135.61.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 16:29:29 +0000 Received: from DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::dd36:d639:9b7b:e886]) by DB8PR06MB6521.eurprd06.prod.outlook.com ([fe80::dd36:d639:9b7b:e886%6]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 16:29:29 +0000 From: "Winfield, Alister" To: Tommy Pauly , Ben Schwartz CC: "Deen, Glenn (NBC Universal - Guest)" , Alissa Cooper , Ted Lemon , ADD Mailing list , =?utf-8?B?Ik1pcmphIEvDvGhsZXdpbmQgKElFVEYpIg==?= , Stephen Farrell Thread-Topic: [EXTERNAL] Re: [Add] A proposed charter for ABCD Thread-Index: AQHVxz9JmWuBpd+SzUuSPFqRPFm94qfquN6AgAARY4CAASkkgA== Date: Wed, 15 Jan 2020 16:29:28 +0000 Message-ID: References: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> In-Reply-To: <76771D7A-3DBD-4A9A-BFDA-DF89226466AA@apple.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alister.Winfield@sky.uk; x-originating-ip: [78.86.25.108] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 02874bb8-c83f-465e-11d2-08d799d817fa x-ms-traffictypediagnostic: DB8PR06MB6474:|DB8PR06MB6474: x-ld-processed: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(376002)(39860400002)(346002)(189003)(199004)(5660300002)(316002)(53546011)(66946007)(66476007)(66556008)(6486002)(4326008)(110136005)(54906003)(71200400001)(64756008)(6506007)(8676002)(66446008)(2906002)(33656002)(76116006)(91956017)(8936002)(86362001)(36756003)(2616005)(81166006)(478600001)(186003)(966005)(6512007)(66574012)(26005)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB8PR06MB6474; H:DB8PR06MB6521.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 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: lCjgQGkWqRp9meSCs8hik4eFwDyF4Xou5xfNZuvQJ1OlPEDI715KnEYuyFVUBJyCvSivNjoFuuQ+MKyG8dBVBY1WQk36kMA5JoK9Wvpb5aPOmKkZ1mBXwfMcgTq8Tn4RJBei1RBLMzJxPV4nP/izZ5ObYrs8WQaTVj4ypHsNtIRY4kh3uCjnIWaPP8SGN/Cv9tIWYDR1G/ZnMuTtL7Ie5lEaOQ6BFs/pH4ZEf56Zz22iAj/KHFttGvpnO/SSfpJWbN91POJWNmY7ukK2CpH4eVDKja7q5iyyQ0ct4wZsOXw6tm9MZFRTZ1gWPcoDlCOeZD7Unycqg/7UXovcU2K2NQo+qyKvSeRLzjCAptG8HDK9S6bExRMblhp2ktR6dcAzayglgJrhFaW3ZqbGYU4/LyJ1N1G0zTnk5yKv0iDorPbfc5FeeRuQBUbGQf7ZuuVf1LlXSbIfgDOn/RA6C5q2DMfDeTr5eeeUmR9qCogBpuCYIiGYPwNyJtMtnnYwjkfyJ6iwSkGIfKCLrNFl/ugM6w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E78736F82126423784AD0FCDCC86F6DEskyuk_" MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 02874bb8-c83f-465e-11d2-08d799d817fa X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 16:29:28.9697 (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: Euf/iHIgr+chLwZyXP+ZSYQIsI3yC4ZN/K1tAGfssaK4K78adfi585W+D95aatPKSdpr77AYlA0xp3q164O11A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR06MB6474 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: A proposed charter for ABCD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 16:29:36 -0000 --_000_E78736F82126423784AD0FCDCC86F6DEskyuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzZWUgdGhpcyByZXZpc2lvbiBhcyBnb29kIHByb2dyZXNzIGFuZCBzdXBwb3J0IHRoaXMgY2hh cnRlciBwcm9wb3NhbC4NCg0KQWxpc3RlciBXaW5maWVsZC4NCg0KRnJvbTogQWRkIDxhZGQtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5j b21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCAxNCBKYW51YXJ5IDIwMjAgYXQgMjI6 NDYNClRvOiBCZW4gU2Nod2FydHogPGJlbWFzYz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+ DQpDYzogIkRlZW4sIEdsZW5uIChOQkMgVW5pdmVyc2FsIC0gR3Vlc3QpIiA8R2xlbm4uRGVlbkBu YmN1bmkuY29tPiwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+LCBUZWQgTGVtb24g PG1lbGxvbkBmdWd1ZS5jb20+LCBBREQgTWFpbGluZyBsaXN0IDxhZGRAaWV0Zi5vcmc+LCAiIk1p cmphIEvDvGhsZXdpbmQgKElFVEYpIiIgPGlldGZAa3VlaGxld2luZC5uZXQ+LCBTdGVwaGVuIEZh cnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJl OiBbQWRkXSBBIHByb3Bvc2VkIGNoYXJ0ZXIgZm9yIEFCQ0QNCg0KSGkgQmVuLA0KDQpBcyBhIG5v dGUsIEdsZW5uIGFuZCBJIHdvcmtlZCBvbiBhIHJldmlzaW9uIG9mIHRoaXMgdG9kYXkgdGhhdCBJ IGhhdmUgc2VudCBvdXQgdG8gdGhlIGxpc3QgdGhhdCBzaG91bGQgY292ZXIgbW9zdCBvZiB5b3Vy IGNvbW1lbnRzLg0KDQpBbnl0aGluZyBzcGVjaWZpY2FsbHkgbmFtaW5nICJwb2xpY3kiIGhhcyBi ZWVuIHJlbW92ZWQgdGhyb3VnaG91dCB0aGUgY2hhcnRlciBwcm9wb3NhbC4gV2UgZGlkIHRvc3Mg YXJvdW5kIHRoZSBpZGVhIG9mICJyZXNvbHZlciBiZWhhdmlvciIgYnV0IGVuZGVkIHVwIGJlaW5n IGEgYml0IG1vcmUgZ2VuZXJhbCBpbiByZWZlcnJpbmcgdG8gaW5mb3JtYXRpb24gYWJvdXQgdGhl IHJlc29sdmVyLCB0aGF0IGNhbiBiZSB1c2VkIGluIHJlc29sdmVyIHNlbGVjdGlvbi4gVGhlIG1h aW4gZ29hbCBoZXJlIGlzIHRvIHByb3ZpZGUgYSBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBpbiB0 aGUgSUVURiBzcGVjIGZvciBwcm9wZXJ0aWVzIHRoYXQgZGVzY3JpYmUgd2hhdCBhIHJlc29sdmVy IHdpbGwgc2VydmUsIHRoZSBtb3N0IGNvbmNyZXRlIGV4YW1wbGUgb2Ygd2hpY2ggaXMgaW5mb3Jt YXRpb24gYWJvdXQgc2VydmluZyBzcGxpdCBETlMgbmFtZXMuIFRoaXMgY29tbXVuaWNhdGlvbiBt ZWNoYW5pc20gY291bGQgYmUgdXNlZCBmb3IgInBvbGljeSIgb3IgImJlaGF2aW9yIiBpbmZvcm1h dGlvbiwgYnV0IHRoYXQgd291bGQgY2VydGFpbmx5IGJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyB3 b3JraW5nIGdyb3VwLg0KDQpXaXRoIHJlZ2FyZHMgdG8gdGhlIHRleHQgZm9yICJzZWN1cml0eSBw cm9wZXJ0aWVzIiwgdGhpcyBtYWlubHkgY2FtZSBmcm9tIGJvaWxlcnBsYXRlIHNlY3VyaXR5IGNo YXJ0ZXIgdGV4dC4gSSBkb24ndCByZWFkIHRoYXQgYXMgbmVjZXNzYXJpbHkgcnVsaW5nIG91dCBv cHBvcnR1bmlzdGljIHVzZSBvZiBlbmNyeXB0aW9uIGFzIGEgc3RyYXRlZ3ksIGJ1dCBhbnkgY29t bXVuaWNhdGlvbiBvZiBleHBsaWNpdCBpbmZvcm1hdGlvbiBiZXR3ZWVuIHR3byBwYXJ0aWVzIChz ZXJ2ZXJzIGFuZCBjbGllbnRzIGluIHRoaXMgZXhhbXBsZSkgc2hvdWxkIGJlIHNwZWNpZmllZCB0 byBiZSBzZWN1cmUuIEkgd291bGQgYXJndWUgdGhhdCBqdXN0IHRyeWluZyBEb0ggdG8gYSBnaXZl biBhZGRyZXNzIGRvZXMgZ2l2ZSB5b3UgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgSFRUUFMg d2hlbiB5b3UgdXNlIHRoYXQ7IGJ1dCB0aGF0J3MgYWxzbyBub3QgYW55IG5ldyBwcm90b2NvbCBt ZWNoYW5pc20uDQoNCkJlc3QsDQpUb21teQ0KDQoNCk9uIEphbiAxNCwgMjAyMCwgYXQgMTo0MyBQ TSwgQmVuIFNjaHdhcnR6IDxiZW1hc2M9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzpiZW1hc2M9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNClRoYW5rcyBm b3IgYXR0ZW1wdGluZyBhIGNvbnNlbnN1cyBjaGFydGVyLCBHbGVubi4gIFNvbWUgY29tbWVudHMg aW5saW5lLg0KDQpPbiBUaHUsIEphbiA5LCAyMDIwIGF0IDU6NTYgUE0gRGVlbiwgR2xlbm4gKE5C Q1VuaXZlcnNhbCkgPEdsZW5uLkRlZW5AbmJjdW5pLmNvbTxtYWlsdG86R2xlbm4uRGVlbkBuYmN1 bmkuY29tPj4gd3JvdGU6DQouLi4NCj4gUHJvcG9zZWQgV29ya2luZyBHcm91cCBDaGFydGVyDQou Li4NCj4NCj4gTmV0d29yayBvcGVyYXRvcnMgdGhhdCBzdGFydCBvZmZlcmluZyBETlMgZW5jcnlw dGlvbiBvbiB0aGVpciBzZXJ2ZXJzDQo+IG5lZWQgYSB3YXkgdG8gaW5kaWNhdGUgdGhpcyBzdXBw b3J0IHRvIGNsaWVudHMuIEJleW9uZCBzdXBwb3J0IGZvcg0KPiBlbmNyeXB0ZWQgRE5TLCBsb2Nh bCBuZXR3b3JrcyBtYXkgYWxzbyBoYXZlIHBvbGljeSBhYm91dCB0aGUgdXNlIG9mIEROUw0KPiB0 byBub24tbG9jYWwgRE5TIHNlcnZlcnMuIENvbW11bmljYXRpbmcgc3VjaCBuZXR3b3JrIHBvbGlj eSB0byBjbGllbnRzDQo+IHdvdWxkIGFsbG93IGNsaWVudHMgdG8gbWFrZSBtb3JlIGluZm9ybWVk IGRlY2lzaW9ucyBhYm91dCB3aGljaCBETlMNCj4gc2VydmVycyB0byB1c2UuDQoNCkkgZmVlbCBz dHJvbmdseSB0aGF0IHdlIHNob3VsZCBhdm9pZCAicG9saWN5IiBpbiB0aGUgV0cgc2NvcGUgdGV4 dC4gIFdlIGFwcGVhciB0byBsYWNrIGEgc2hhcmVkIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0aGlz IHdvcmQgbWVhbnMsIGFuZCBpdCBpcyB0aGUgZm9jdXMgb2YgbXVjaCBjb25mbGljdCBoZXJlLiAg SW5jbHVkaW5nIGl0IGhlcmUgc2VlbXMgbGlrZSBhIHJlY2lwZSBmb3IgY29uZnJvbnRhdGlvbiB3 aXRoaW4gdGhlIHdvcmtpbmcgZ3JvdXAuICBJIGFsc28gZG9uJ3QgdGhpbmsgaXQncyBuZWNlc3Nh cnkgZm9yIGFsbW9zdCBhbnkgb2YgdGhlIGdvYWxzIG1lbnRpb25lZCBvbiB0aGlzIGxpc3Q6IHdl IGNhbiByZXBocmFzZSBpbiBhIHdheSB0aGF0IGlzIGJvdGggY2xlYXJlciBhbmQgbW9yZSBicm9h ZGx5IGFjY2VwdGFibGUuDQoNCkluIHRoaXMgY2FzZSwgSSB3b3VsZCBzdWdnZXN0OiAiLi4uIHNl cnZlcnMgbmVlZCBhIHdheSB0byBpbmRpY2F0ZSB0aGlzIHN1cHBvcnQgdG8gY2xpZW50cy4gIENs aWVudHMgbWF5IGFsc28gYmUgYWJsZSB0byBtYWtlIGJldHRlciBkZWNpc2lvbnMgYWJvdXQgd2hp Y2ggRE5TIHNlcnZlcnMgdG8gdXNlIGlmIHRoZXkgY2FuIGxlYXJuIG1vcmUgYWJvdXQgdGhlIHJl c29sdXRpb24gYmVoYXZpb3JzIG9mIGVhY2ggc2VydmVyLiIuDQoNCj4gVGhlIEFkYXB0aXZlIERO UyBEaXNjb3ZlcnkgKEFERCkgd29ya2luZyBncm91cCB3aWxsIGRlZmluZSBtZWNoYW5pc21zIGFu ZA0KPiBwcm90b2NvbHMgdG86DQouLi4NCj4gLSBhbGxvdyBuZXR3b3JrIHByb3ZpZGVycyB0byBj b21tdW5pY2F0ZSBETlMgcG9saWN5IHRvIGNsaWVudHMsDQo+IGluY2x1ZGluZyBpbmZvcm1hdGlv biBhYm91dCBsb2NhbGx5LWFjY2Vzc2libGUgbmFtZXM7DQoNCkluIHRoaXMgY2FzZSwgSSB3b3Vs ZCByZXBocmFzZSBhcyAiLi4uIGNvbW11bmljYXRlIGluZm9ybWF0aW9uIGFib3V0IHJlc29sdmVy IGJlaGF2aW9yIHRvIGNsaWVudHMsIGluY2x1ZGluZyAuLi4uIi4NCg0KLi4uDQo+IEFueSBtZWNo YW5pc21zIHRoYXQgc3BlY2lmeSBpbnRlcmFjdGlvbnMgYmV0d2VlbiBjbGllbnRzIGFuZA0KPiBz ZXJ2ZXJzIG11c3QgcHJvdmlkZSB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBleHBlY3RlZCBvZiBJ RVRGDQo+IHByb3RvY29scywgZS5nLiwgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24sIGludGVn cml0eSBwcm90ZWN0aW9uLA0KPiBhbmQgYXV0aGVudGljYXRpb24gd2l0aCBzdHJvbmcgd29yayBm YWN0b3IuDQoNClRoaXMgYXBwZWFycyB0byBydWxlIG91dCBvcHBvcnR1bmlzdGljIHVwZ3JhZGUg dG8gRG9ILCBhcyB3ZWxsIGFzIHRoZSBlbnRpcmUgUkVTSU5GTyBmcmFtZXdvcmsgYWRvcHRlZCBi eSBETlNPUC4gIFBlcnNvbmFsbHksIEkgZG9uJ3QgdGhpbmsgInRoZSBzZWN1cml0eSBwcm9wZXJ0 aWVzIGV4cGVjdGVkIG9mIElFVEYgcHJvdG9jb2xzIiBhcmUgY29tcGF0aWJsZSB3aXRoIG1vc3Qg b2YgdGhlIHVzZSBjYXNlcyB3ZSd2ZSBkaXNjdXNzZWQsIGluY2x1ZGluZyB0aGUgb25lcyBtZW50 aW9uZWQgaW4gdGhpcyBjaGFydGVyIHRleHQuICBJIHRoaW5rIHdlIHdvdWxkIGJlIGJldHRlciBv ZmYgZmxpcHBpbmcgdGhpcyB0byBleHBsaWNpdGx5IGZvY3VzIG9uIG9wcG9ydHVuaXN0aWMgcHJv dG9jb2xzLCBhbmQgcHJvbWlzZSB0byBkb2N1bWVudCBhcHByb3ByaWF0ZSBndWFyZHJhaWxzIGFn YWluc3QgaW1wcm9wZXIgcmVsaWFuY2Ugb24gc2VjdXJpdHkgcHJvcGVydGllcyB0aGF0IGFyZSBu b3QgcHJvdmlkZWQuDQoNCldoaWxlIG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaXMgbm90IHRvIGJl IHJlbGllZCBvbiBmb3IgY3J1Y2lhbCBzZWN1cml0eSBwcm9wZXJ0aWVzLCBJIHRoaW5rIG9wcG9y dHVuaXN0aWMgcHJpdmFjeSAoYWdhaW5zdCBhIHBhc3NpdmUgYWR2ZXJzYXJ5KSBpcyB2YWx1YWJs ZSBhbmQgd29ydGggaW5jbHVkaW5nIGluIHRoZSB3b3JraW5nIGdyb3VwJ3Mgc2NvcGUuICBBbHNv LCBvcHBvcnR1bmlzdGljIHVwZ3JhZGUgd291bGQgZ2l2ZSBjbGllbnRzIGEgY2xlYXIgaW5kaWNh dGlvbiB0aGF0IHRoZXkgYXJlIHNwZWFraW5nIGRpcmVjdGx5IHRvIGEgbW9kZXJuIHJlc29sdmVy LCBhbGxvd2luZyB0aGVtIHRvIHJlbHkgb24gbW9kZXJuIEROUyBmZWF0dXJlcy4gIEluIHRoZSBh YnNlbmNlIG9mIHN1Y2ggYSBzaWduYWwsIGNsaWVudHMgY2Fubm90IHJlbHkgb24gYW55IEROUyBm ZWF0dXJlcyBiZXlvbmQgYmFzaWMgQS9BQUFBIHF1ZXJpZXMsIGR1ZSB0byB0aGUgbGluZ2VyaW5n IGRlcGxveW1lbnQgb2YgYnVnZ3kgcmVzb2x2ZXJzLCBmb3J3YXJkZXJzLCBhbmQgbWlkZGxlYm94 ZXMuICBJIGtub3cgdGhhdCB0aGlzIGhhcyBiZWVuIGEgbWFqb3IgZmFjdG9yIGluIHBvcHVsYXIg Y2xpZW50cycgZGVjaXNpb25zIG5vdCB0byBtYWtlIHVzZSBvZiBFRE5TLCBETlNTRUMsIGFuZCBv dGhlciBtb2Rlcm4gRE5TIGZlYXR1cmVzLg0KLS0NCkFkZCBtYWlsaW5nIGxpc3QNCkFkZEBpZXRm Lm9yZzxtYWlsdG86QWRkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hZGQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgZW1haWwgaXMgZnJvbSBhbiBleHRlcm5h bCBzb3VyY2UuIFBsZWFzZSBkbyBub3Qgb3BlbiBhdHRhY2htZW50cyBvciBjbGljayBsaW5rcyBm cm9tIGFuIHVua25vd24gb3Igc3VzcGljaW91cyBvcmlnaW4uIFBoaXNoaW5nIGF0dGVtcHRzIGNh biBiZSByZXBvcnRlZCBieSBzZW5kaW5nIHRoZW0gdG8gcGhpc2hpbmdAc2t5LnVrIGFzIGF0dGFj aG1lbnRzLiBUaGFuayB5b3UNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkluZm9ybWF0aW9uIGluIHRoaXMgZW1h aWwgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cyBtYXkgYmUgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsIGFuZCBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgdGhlIGFkZHJlc3NlZS4gVGhlIHZp ZXdzIGV4cHJlc3NlZCBtYXkgbm90IGJlIG9mZmljaWFsIHBvbGljeSwgYnV0IHRoZSBwZXJzb25h bCB2aWV3cyBvZiB0aGUgb3JpZ2luYXRvci4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUg aXQgZnJvbSB5b3VyIHN5c3RlbS4gWW91IHNob3VsZCBub3QgcmVwcm9kdWNlLCBkaXN0cmlidXRl LCBzdG9yZSwgcmV0cmFuc21pdCwgdXNlIG9yIGRpc2Nsb3NlIGl0cyBjb250ZW50cyB0byBhbnlv bmUuIFBsZWFzZSBub3RlIHdlIHJlc2VydmUgdGhlIHJpZ2h0IHRvIG1vbml0b3IgYWxsIGUtbWFp bCBjb21tdW5pY2F0aW9uIHRocm91Z2ggb3VyIGludGVybmFsIGFuZCBleHRlcm5hbCBuZXR3b3Jr cy4gU0tZIGFuZCB0aGUgU0tZIG1hcmtzIGFyZSB0cmFkZW1hcmtzIG9mIFNreSBMaW1pdGVkIGFu ZCBTa3kgSW50ZXJuYXRpb25hbCBBRyBhbmQgYXJlIHVzZWQgdW5kZXIgbGljZW5jZS4NCg0KU2t5 IFVLIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjkwNjk5MSksIFNreS1Jbi1Ib21lIFNlcnZp Y2UgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMDY3MDc1KSwgU2t5IFN1YnNjcmliZXJzIFNl cnZpY2VzIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjM0MDE1MCkgYW5kIFNreSBDUCBMaW1p dGVkIChSZWdpc3RyYXRpb24gTm8uIDk1MTMyNTkpIGFyZSBkaXJlY3Qgb3IgaW5kaXJlY3Qgc3Vi c2lkaWFyaWVzIG9mIFNreSBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIyNDc3MzUpLiBBbGwg b2YgdGhlIGNvbXBhbmllcyBtZW50aW9uZWQgaW4gdGhpcyBwYXJhZ3JhcGggYXJlIGluY29ycG9y YXRlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyBhbmQgc2hhcmUgdGhlIHNhbWUgcmVnaXN0ZXJlZCBv ZmZpY2UgYXQgR3JhbnQgV2F5LCBJc2xld29ydGgsIE1pZGRsZXNleCBUVzcgNVFEDQo= --_000_E78736F82126423784AD0FCDCC86F6DEskyuk_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNYWxndW4g R290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgdGhpcyByZXZpc2lvbiBhcyBn b29kIHByb2dyZXNzIGFuZCBzdXBwb3J0IHRoaXMgY2hhcnRlciBwcm9wb3NhbC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxpc3RlciBXaW5maWVsZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkFkZCAmbHQ7YWRkLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJl aGFsZiBvZiBUb21teSBQYXVseSAmbHQ7dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3Jn Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCAxNCBKYW51YXJ5IDIwMjAgYXQgMjI6NDY8 YnI+DQo8Yj5UbzogPC9iPkJlbiBTY2h3YXJ0eiAmbHQ7YmVtYXNjPTQwZ29vZ2xlLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O0RlZW4sIEdsZW5uIChOQkMgVW5p dmVyc2FsIC0gR3Vlc3QpJnF1b3Q7ICZsdDtHbGVubi5EZWVuQG5iY3VuaS5jb20mZ3Q7LCBBbGlz c2EgQ29vcGVyICZsdDthbGlzc2FAY29vcGVydy5pbiZndDssIFRlZCBMZW1vbiAmbHQ7bWVsbG9u QGZ1Z3VlLmNvbSZndDssIEFERCBNYWlsaW5nIGxpc3QgJmx0O2FkZEBpZXRmLm9yZyZndDssICZx dW90OyZxdW90O01pcmphIEvDvGhsZXdpbmQgKElFVEYpJnF1b3Q7JnF1b3Q7ICZsdDtpZXRmQGt1 ZWhsZXdpbmQubmV0Jmd0OywgU3RlcGhlbiBGYXJyZWxsICZsdDtzdGVwaGVuLmZhcnJlbGxAY3Mu dGNkLmllJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bRVhURVJOQUxdIFJlOiBbQWRkXSBBIHBy b3Bvc2VkIGNoYXJ0ZXIgZm9yIEFCQ0Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQmVuLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFzIGEgbm90ZSwgR2xlbm4gYW5kIEkgd29ya2VkIG9uIGEgcmV2 aXNpb24gb2YgdGhpcyB0b2RheSB0aGF0IEkgaGF2ZSBzZW50IG91dCB0byB0aGUgbGlzdCB0aGF0 IHNob3VsZCBjb3ZlciBtb3N0IG9mIHlvdXIgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueXRoaW5nIHNwZWNpZmljYWxseSBu YW1pbmcgJnF1b3Q7cG9saWN5JnF1b3Q7IGhhcyBiZWVuIHJlbW92ZWQgdGhyb3VnaG91dCB0aGUg Y2hhcnRlciBwcm9wb3NhbC4gV2UgZGlkIHRvc3MgYXJvdW5kIHRoZSBpZGVhIG9mICZxdW90O3Jl c29sdmVyIGJlaGF2aW9yJnF1b3Q7IGJ1dCBlbmRlZCB1cCBiZWluZyBhIGJpdCBtb3JlIGdlbmVy YWwgaW4gcmVmZXJyaW5nIHRvIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXNvbHZlciwgdGhhdCBj YW4gYmUNCiB1c2VkIGluIHJlc29sdmVyIHNlbGVjdGlvbi4gVGhlIG1haW4gZ29hbCBoZXJlIGlz IHRvIHByb3ZpZGUgYSBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBpbiB0aGUgSUVURiBzcGVjIGZv ciBwcm9wZXJ0aWVzIHRoYXQgZGVzY3JpYmUgd2hhdCBhIHJlc29sdmVyIHdpbGwgc2VydmUsIHRo ZSBtb3N0IGNvbmNyZXRlIGV4YW1wbGUgb2Ygd2hpY2ggaXMgaW5mb3JtYXRpb24gYWJvdXQgc2Vy dmluZyBzcGxpdCBETlMgbmFtZXMuIFRoaXMgY29tbXVuaWNhdGlvbg0KIG1lY2hhbmlzbSBjb3Vs ZCBiZSB1c2VkIGZvciAmcXVvdDtwb2xpY3kmcXVvdDsgb3IgJnF1b3Q7YmVoYXZpb3ImcXVvdDsg aW5mb3JtYXRpb24sIGJ1dCB0aGF0IHdvdWxkIGNlcnRhaW5seSBiZSBvdXQgb2Ygc2NvcGUgZm9y IHRoaXMgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2l0aCByZWdhcmRzIHRvIHRoZSB0ZXh0IGZvciAmcXVvdDtzZWN1 cml0eSBwcm9wZXJ0aWVzJnF1b3Q7LCB0aGlzIG1haW5seSBjYW1lIGZyb20gYm9pbGVycGxhdGUg c2VjdXJpdHkgY2hhcnRlciB0ZXh0LiBJIGRvbid0IHJlYWQgdGhhdCBhcyBuZWNlc3NhcmlseSBy dWxpbmcgb3V0IG9wcG9ydHVuaXN0aWMgdXNlIG9mIGVuY3J5cHRpb24gYXMgYSBzdHJhdGVneSwg YnV0IGFueSBjb21tdW5pY2F0aW9uIG9mIGV4cGxpY2l0IGluZm9ybWF0aW9uDQogYmV0d2VlbiB0 d28gcGFydGllcyAoc2VydmVycyBhbmQgY2xpZW50cyBpbiB0aGlzIGV4YW1wbGUpIHNob3VsZCBi ZSBzcGVjaWZpZWQgdG8gYmUgc2VjdXJlLiBJIHdvdWxkIGFyZ3VlIHRoYXQganVzdCB0cnlpbmcg RG9IIHRvIGEgZ2l2ZW4gYWRkcmVzcyBkb2VzIGdpdmUgeW91IHRoZSBzZWN1cml0eSBwcm9wZXJ0 aWVzIG9mIEhUVFBTIHdoZW4geW91IHVzZSB0aGF0OyBidXQgdGhhdCdzIGFsc28gbm90IGFueSBu ZXcgcHJvdG9jb2wgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvbW15PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEphbiAxNCwgMjAyMCwgYXQgMTo0MyBQTSwgQmVuIFNjaHdhcnR6 ICZsdDs8YSBocmVmPSJtYWlsdG86YmVtYXNjPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyI+ YmVtYXNjPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBhdHRlbXB0 aW5nIGEgY29uc2Vuc3VzIGNoYXJ0ZXIsIEdsZW5uLiZuYnNwOyBTb21lIGNvbW1lbnRzIGlubGlu ZS48YnI+DQo8YnI+DQpPbiBUaHUsIEphbiA5LCAyMDIwIGF0IDU6NTYgUE0gRGVlbiwgR2xlbm4g KE5CQ1VuaXZlcnNhbCkgJmx0OzxhIGhyZWY9Im1haWx0bzpHbGVubi5EZWVuQG5iY3VuaS5jb20i PkdsZW5uLkRlZW5AbmJjdW5pLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCi4uLiA8YnI+DQomZ3Q7 IFByb3Bvc2VkIFdvcmtpbmcgR3JvdXAgQ2hhcnRlcjxicj4NCi4uLiAmbmJzcDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBOZXR3b3JrIG9wZXJhdG9ycyB0aGF0IHN0YXJ0IG9mZmVyaW5nIEROUyBlbmNy eXB0aW9uIG9uIHRoZWlyIHNlcnZlcnM8YnI+DQomZ3Q7IG5lZWQgYSB3YXkgdG8gaW5kaWNhdGUg dGhpcyBzdXBwb3J0IHRvIGNsaWVudHMuIEJleW9uZCBzdXBwb3J0IGZvcjxicj4NCiZndDsgZW5j cnlwdGVkIEROUywgbG9jYWwgbmV0d29ya3MgbWF5IGFsc28gaGF2ZSBwb2xpY3kgYWJvdXQgdGhl IHVzZSBvZiBETlM8YnI+DQomZ3Q7IHRvIG5vbi1sb2NhbCBETlMgc2VydmVycy4gQ29tbXVuaWNh dGluZyBzdWNoIG5ldHdvcmsgcG9saWN5IHRvIGNsaWVudHM8YnI+DQomZ3Q7IHdvdWxkIGFsbG93 IGNsaWVudHMgdG8gbWFrZSBtb3JlIGluZm9ybWVkIGRlY2lzaW9ucyBhYm91dCB3aGljaCBETlM8 YnI+DQomZ3Q7IHNlcnZlcnMgdG8gdXNlLjxicj4NCjxicj4NCkkgZmVlbCBzdHJvbmdseSB0aGF0 IHdlIHNob3VsZCBhdm9pZCAmcXVvdDtwb2xpY3kmcXVvdDsgaW4gdGhlIFdHIHNjb3BlIHRleHQu Jm5ic3A7IFdlIGFwcGVhciB0byBsYWNrIGEgc2hhcmVkIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCB0 aGlzIHdvcmQgbWVhbnMsIGFuZCBpdCBpcyB0aGUgZm9jdXMgb2YgbXVjaCBjb25mbGljdCBoZXJl LiZuYnNwOyBJbmNsdWRpbmcgaXQgaGVyZSBzZWVtcyBsaWtlIGEgcmVjaXBlIGZvciBjb25mcm9u dGF0aW9uIHdpdGhpbiB0aGUgd29ya2luZyBncm91cC4mbmJzcDsNCiBJIGFsc28gZG9uJ3QgdGhp bmsgaXQncyBuZWNlc3NhcnkgZm9yIGFsbW9zdCBhbnkgb2YgdGhlIGdvYWxzIG1lbnRpb25lZCBv biB0aGlzIGxpc3Q6IHdlIGNhbiByZXBocmFzZSBpbiBhIHdheSB0aGF0IGlzIGJvdGggY2xlYXJl ciBhbmQgbW9yZSBicm9hZGx5IGFjY2VwdGFibGUuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoaXMgY2FzZSwgSSB3b3VsZCBzdWdnZXN0OiAmcXVv dDsuLi4gc2VydmVycyBuZWVkIGEgd2F5IHRvIGluZGljYXRlIHRoaXMgc3VwcG9ydCB0byBjbGll bnRzLiZuYnNwOyBDbGllbnRzIG1heSBhbHNvIGJlIGFibGUgdG8gbWFrZSBiZXR0ZXIgZGVjaXNp b25zIGFib3V0IHdoaWNoIEROUyBzZXJ2ZXJzIHRvIHVzZSBpZiB0aGV5IGNhbiBsZWFybiBtb3Jl IGFib3V0IHRoZSByZXNvbHV0aW9uIGJlaGF2aW9ycyBvZiBlYWNoDQogc2VydmVyLiZxdW90Oy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IFRo ZSBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUg bWVjaGFuaXNtcyBhbmQ8YnI+DQomZ3Q7IHByb3RvY29scyB0bzo8YnI+DQouLi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLSBhbGxvdyBu ZXR3b3JrIHByb3ZpZGVycyB0byBjb21tdW5pY2F0ZSBETlMgcG9saWN5IHRvIGNsaWVudHMsPGJy Pg0KJmd0OyBpbmNsdWRpbmcgaW5mb3JtYXRpb24gYWJvdXQgbG9jYWxseS1hY2Nlc3NpYmxlIG5h bWVzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiB0aGlzIGNhc2UsIEkgd291bGQgcmVwaHJhc2UgYXMgJnF1b3Q7Li4uIGNvbW11bmljYXRl IGluZm9ybWF0aW9uIGFib3V0IHJlc29sdmVyIGJlaGF2aW9yIHRvIGNsaWVudHMsIGluY2x1ZGlu ZyAuLi4uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IEFueSBtZWNoYW5pc21zIHRoYXQgc3BlY2lmeSBpbnRlcmFjdGlv bnMgYmV0d2VlbiBjbGllbnRzIGFuZDxicj4NCiZndDsgc2VydmVycyBtdXN0IHByb3ZpZGUgdGhl IHNlY3VyaXR5IHByb3BlcnRpZXMgZXhwZWN0ZWQgb2YgSUVURjxicj4NCiZndDsgcHJvdG9jb2xz LCBlLmcuLCBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiwgaW50ZWdyaXR5IHByb3RlY3Rpb24s PGJyPg0KJmd0OyBhbmQgYXV0aGVudGljYXRpb24gd2l0aCBzdHJvbmcgd29yayBmYWN0b3IuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg YXBwZWFycyB0byBydWxlIG91dCBvcHBvcnR1bmlzdGljIHVwZ3JhZGUgdG8gRG9ILCBhcyB3ZWxs IGFzIHRoZSBlbnRpcmUgUkVTSU5GTyBmcmFtZXdvcmsgYWRvcHRlZCBieSBETlNPUC4mbmJzcDsg UGVyc29uYWxseSwgSSBkb24ndCB0aGluayAmcXVvdDt0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBl eHBlY3RlZCBvZiBJRVRGIHByb3RvY29scyZxdW90OyBhcmUgY29tcGF0aWJsZSB3aXRoIG1vc3Qg b2YgdGhlIHVzZSBjYXNlcyB3ZSd2ZQ0KIGRpc2N1c3NlZCwgaW5jbHVkaW5nIHRoZSBvbmVzIG1l bnRpb25lZCBpbiB0aGlzIGNoYXJ0ZXIgdGV4dC4mbmJzcDsgSSB0aGluayB3ZSB3b3VsZCBiZSBi ZXR0ZXIgb2ZmIGZsaXBwaW5nIHRoaXMgdG8gZXhwbGljaXRseSBmb2N1cyBvbiBvcHBvcnR1bmlz dGljIHByb3RvY29scywgYW5kIHByb21pc2UgdG8gZG9jdW1lbnQgYXBwcm9wcmlhdGUgZ3VhcmRy YWlscyBhZ2FpbnN0IGltcHJvcGVyIHJlbGlhbmNlIG9uIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhh dA0KIGFyZSBub3QgcHJvdmlkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaXMgbm90IHRv IGJlIHJlbGllZCBvbiBmb3IgY3J1Y2lhbCBzZWN1cml0eSBwcm9wZXJ0aWVzLCBJIHRoaW5rIG9w cG9ydHVuaXN0aWMgcHJpdmFjeSAoYWdhaW5zdCBhIHBhc3NpdmUgYWR2ZXJzYXJ5KSBpcyZuYnNw O3ZhbHVhYmxlIGFuZCB3b3J0aCBpbmNsdWRpbmcgaW4gdGhlIHdvcmtpbmcgZ3JvdXAncyBzY29w ZS4mbmJzcDsgQWxzbywgb3Bwb3J0dW5pc3RpYyB1cGdyYWRlDQogd291bGQgZ2l2ZSBjbGllbnRz IGEgY2xlYXIgaW5kaWNhdGlvbiB0aGF0IHRoZXkgYXJlIHNwZWFraW5nIGRpcmVjdGx5IHRvIGEg bW9kZXJuIHJlc29sdmVyLCBhbGxvd2luZyB0aGVtIHRvIHJlbHkgb24gbW9kZXJuIEROUyBmZWF0 dXJlcy4mbmJzcDsgSW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBhIHNpZ25hbCwgY2xpZW50cyBjYW5u b3QgcmVseSBvbiBhbnkgRE5TIGZlYXR1cmVzIGJleW9uZCBiYXNpYyBBL0FBQUEgcXVlcmllcywg ZHVlIHRvIHRoZSBsaW5nZXJpbmcNCiBkZXBsb3ltZW50IG9mIGJ1Z2d5IHJlc29sdmVycywgZm9y d2FyZGVycywgYW5kIG1pZGRsZWJveGVzLiZuYnNwOyBJIGtub3cgdGhhdCB0aGlzIGhhcyBiZWVu IGEgbWFqb3IgZmFjdG9yIGluIHBvcHVsYXIgY2xpZW50cycmbmJzcDtkZWNpc2lvbnMgbm90IHRv IG1ha2UgdXNlIG9mIEVETlMsIEROU1NFQywgYW5kIG90aGVyIG1vZGVybiBETlMgZmVhdHVyZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLSA8YnI+DQpBZGQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFkZEBp ZXRmLm9yZyI+QWRkQGlldGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWRkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpj ZW50ZXIiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlciI+DQo8Yj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBl bWFpbCBpcyBmcm9tIGFuIGV4dGVybmFsIHNvdXJjZS4gUGxlYXNlIGRvIG5vdCBvcGVuIGF0dGFj aG1lbnRzIG9yIGNsaWNrIGxpbmtzIGZyb20gYW4gdW5rbm93biBvciBzdXNwaWNpb3VzIG9yaWdp bi4gUGhpc2hpbmcgYXR0ZW1wdHMgY2FuIGJlIHJlcG9ydGVkIGJ5IHNlbmRpbmcgdGhlbSB0byBw aGlzaGluZ0Bza3kudWsgYXMgYXR0YWNobWVudHMuDQogVGhhbmsgeW91PC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOmNlbnRlciI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQpJbmZvcm1hdGlvbiBpbiB0aGlzIGVtYWlsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMgbWF5 IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg Zm9yIHRoZSBhZGRyZXNzZWUuIFRoZSB2aWV3cyBleHByZXNzZWQgbWF5IG5vdCBiZSBvZmZpY2lh bCBwb2xpY3ksIGJ1dCB0aGUgcGVyc29uYWwgdmlld3Mgb2YgdGhlIG9yaWdpbmF0b3IuIElmIHlv dSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2UNCiBub3RpZnkgdGhlIHNlbmRlciBi eSByZXR1cm4gZS1tYWlsIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4gWW91IHNob3Vs ZCBub3QgcmVwcm9kdWNlLCBkaXN0cmlidXRlLCBzdG9yZSwgcmV0cmFuc21pdCwgdXNlIG9yIGRp c2Nsb3NlIGl0cyBjb250ZW50cyB0byBhbnlvbmUuIFBsZWFzZSBub3RlIHdlIHJlc2VydmUgdGhl IHJpZ2h0IHRvIG1vbml0b3IgYWxsIGUtbWFpbCBjb21tdW5pY2F0aW9uIHRocm91Z2ggb3VyIGlu dGVybmFsIGFuZA0KIGV4dGVybmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJl IHRyYWRlbWFya3Mgb2YgU2t5IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBh cmUgdXNlZCB1bmRlciBsaWNlbmNlLg0KPGJyPg0KPGJyPg0KU2t5IFVLIExpbWl0ZWQgKFJlZ2lz dHJhdGlvbiBOby4gMjkwNjk5MSksIFNreS1Jbi1Ib21lIFNlcnZpY2UgTGltaXRlZCAoUmVnaXN0 cmF0aW9uIE5vLiAyMDY3MDc1KSwgU2t5IFN1YnNjcmliZXJzIFNlcnZpY2VzIExpbWl0ZWQgKFJl Z2lzdHJhdGlvbiBOby4gMjM0MDE1MCkgYW5kIFNreSBDUCBMaW1pdGVkIChSZWdpc3RyYXRpb24g Tm8uIDk1MTMyNTkpIGFyZSBkaXJlY3Qgb3IgaW5kaXJlY3Qgc3Vic2lkaWFyaWVzIG9mIFNreSBM aW1pdGVkIChSZWdpc3RyYXRpb24NCiBOby4gMjI0NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVz IG1lbnRpb25lZCBpbiB0aGlzIHBhcmFncmFwaCBhcmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQg YW5kIFdhbGVzIGFuZCBzaGFyZSB0aGUgc2FtZSByZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBX YXksIElzbGV3b3J0aCwgTWlkZGxlc2V4IFRXNyA1UUQNCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E78736F82126423784AD0FCDCC86F6DEskyuk_-- From nobody Wed Jan 15 08:49:13 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65693120881 for ; Wed, 15 Jan 2020 08:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 kxiCLqAfmop7 for ; Wed, 15 Jan 2020 08:48:10 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 EA21112009E for ; Wed, 15 Jan 2020 08:48:09 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id z76so16268271qka.2 for ; Wed, 15 Jan 2020 08:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zP+Qrhq63llY4gi44Lxhx8ixxQq0zIGwJfDxsp+UXYc=; b=gNMSzABI7FYa/Ib4fFSVX98wYisW+G9PetAbBWwr2SiVsp+uYa8QDSq1Flya6tbLKw Yklz6x8D1jeWHYwBWxmDUtu3BMzcGOlSQUIQEauVFPnqRlU0Leqw/NTdClTJHo1OgbD4 amfGyVTTx1PXKZMP3SaWOSzHKRA/IK+ro2Ikhib2neO3PR8watSdM27Rx0UgNF8a5T5b D1a+afqzPKsaH2kQsBtjhvA2rEuXTIMAp/e6PMdOjyoNO3Cgs8biPbqV+sKWkMu7RvoP lCiUDr5vWe09HD4fgDNmM7p4ZoOuptv0wtNuLQr19QotCj1raK6Dx6yftcz6ZwVKOcNI CWXw== 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=zP+Qrhq63llY4gi44Lxhx8ixxQq0zIGwJfDxsp+UXYc=; b=kcjy8UgJkN3g09tRC1prPSHJEmHM4NhwFxZRnDbqdaprnmdzqnNcZEYCASyAEfGKXV OO9YDwMVtJ/ZfeDqnglP/FzKcQar0+yzdQao+6/v0mZ3oyXv6LbjyvjTBaPORn7L+mvB qC4okGOUvQ8OTpLzD+jAufe4TlnbZTJlpOUxbffpi6wD4FG9KjX0KyOCe5ptYEcWIAzo 6D9xpuaFP63T+sc/NPsqYdH1svz5Tarc9+dFtNr3Ealmz1+GG6pHREOvu4T0HAtG3oyW AayHkMWs2s1aARLbPbv3tb6B6sJdr52u6OdVpnMKlu6IxhtJ650INWTpcvGMqX9WDEKA x1HA== X-Gm-Message-State: APjAAAUJmnIt/Skv3UP7x8GnSYNyTYv/rl6GowhCHqI+X6vZff6hoCHv /X7wxKLYsPrG9GyTlXVa2ITS9Q== X-Google-Smtp-Source: APXvYqx4UDbOESMtA0gs3ek0J2sSj6aWf/KMSU+dw7bf+QhYNNYW0qvAVEU1R2WWSurBHPXOvJ5Hjg== X-Received: by 2002:ae9:e40d:: with SMTP id q13mr28863387qkc.2.1579106888855; Wed, 15 Jan 2020 08:48:08 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id t38sm9850357qta.78.2020.01.15.08.48.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 08:48:08 -0800 (PST) From: Ted Lemon Message-Id: <85F15EAE-6933-451D-A04F-3DE2907603FB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A2A1ACBB-2C65-4019-B410-95A48471E125" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 15 Jan 2020 11:48:06 -0500 In-Reply-To: Cc: ADD Mailing list To: Paul Hoffman References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 16:48:15 -0000 --Apple-Mail=_A2A1ACBB-2C65-4019-B410-95A48471E125 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 11:18 AM, Paul Hoffman = wrote: > The first sentence is well-intentioned but does not usually lead to = useful text in documents. The second sentence assumes that there are = methods that can be cryptographically validated: as I said above, I do = not believe they exist. Of course such mechanisms exist. The problem is that they can=E2=80=99t = happen without some explicit trust establishment mechanism, which = necessarily requires manual intervention. What I want to capture is that any mechanism that the ADD WG comes up = with that doesn=E2=80=99t have a trust establishment mechanism doesn=E2=80= =99t override a mechanism where trust has been established explicitly = unless there=E2=80=99s some specific reason why that=E2=80=99s the right = thing to do. E.g., Tommy I think mentioned, and this is a use case I = deal with regularly as well, that you might be connected to a network = that uses a split-dns configuration where if you query a public = resolver, you just won=E2=80=99t get an answer for some domain. I think = that there is a pretty strong motivation from some of the participants = to support a use case for CDNs; figuring out how to do this seems like = it would be very much worthwhile, even if such a mechanism doesn=E2=80=99t= come with an explicit trust relationship. I would expect that a trust establishment mechanism based on the ANIMA = on-boarding process (IETF) or the Thread commissioning process (Thread = Group) would also be cryptographically verifiable, since devices = commissioned using either mechanism can in fact cryptographically = validate that they are connected to a particular network; it=E2=80=99s = not a big step past that to validating the resolver. If course, for a = device that doesn=E2=80=99t have any such configuration established, a = simple DHCP mechanism or RA mechanism for getting opportunistic security = is still very much worth doing. That said, I think it is in scope for the WG to talk about configuration = mechanism that require manual intervention and do establish = cryptographically verifiable trust. Do you disagree with that? To me = this seems like an important part of the problem space. --Apple-Mail=_A2A1ACBB-2C65-4019-B410-95A48471E125 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 15, 2020, at 11:18 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
The first sentence is well-intentioned but does not usually = lead to useful text in documents. The second sentence assumes that there = are methods that can be cryptographically validated: as I said above, I = do not believe they exist.

Of course such mechanisms exist.   The = problem is that they can=E2=80=99t happen without some explicit trust = establishment mechanism, which necessarily requires manual = intervention.

What I want to capture is that any mechanism that the ADD WG = comes up with that doesn=E2=80=99t have a trust establishment mechanism = doesn=E2=80=99t override a mechanism where trust has been established = explicitly unless there=E2=80=99s some specific reason why that=E2=80=99s = the right thing to do.  E.g., Tommy I think mentioned, and this is = a use case I deal with regularly as well, that you might be connected to = a network that uses a split-dns configuration where if you query a = public resolver, you just won=E2=80=99t get an answer for some domain. =  I think that there is a pretty strong motivation from some of the = participants to support a use case for CDNs; figuring out how to do this = seems like it would be very much worthwhile, even if such a mechanism = doesn=E2=80=99t come with an explicit trust relationship.

I would expect that a = trust establishment mechanism based on the ANIMA on-boarding process = (IETF) or the Thread commissioning process (Thread Group) would also be = cryptographically verifiable, since devices commissioned using either = mechanism can in fact cryptographically validate that they are connected = to a particular network; it=E2=80=99s not a big step past that to = validating the resolver.   If course, for a device that doesn=E2=80=99= t have any such configuration established, a simple DHCP mechanism or RA = mechanism for getting opportunistic security is still very much worth = doing.

That = said, I think it is in scope for the WG to talk about configuration = mechanism that require manual intervention and do establish = cryptographically verifiable trust.   Do you disagree with that? =   To me this seems like an important part of the problem = space.

= --Apple-Mail=_A2A1ACBB-2C65-4019-B410-95A48471E125-- From nobody Wed Jan 15 09:20:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7191208AA for ; Wed, 15 Jan 2020 09:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=fLUbJ8/G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zcn+pvI7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGp9xIKij3q5 for ; Wed, 15 Jan 2020 09:19:32 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0677A12088B for ; Wed, 15 Jan 2020 09:19:32 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4FB9B22129; Wed, 15 Jan 2020 12:19:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 15 Jan 2020 12:19:31 -0500 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=fm2; bh=W bpUnkk1so8tCnNgiAjw5fxb6FAG9ecCCZi8gvoYNRU=; b=fLUbJ8/GnFrGTZ0OH t77cm1v5Wek7Zb/iDxFDjx4iPUzhSVu3g82fNq3Jr5fzxIXoDdzg3nTGxaghd89n ILNZ6CVjVK75i3HHDm3KcH0Jf7Qp72biMIgt77R3ZWU8tjXt+AKrbTwqz2in5cc0 M53W7uYiykhYQFLFuS53wd3lu4RsMJbwMITP49+BS+FtTDWvrxr/eFdmUUOpAIT4 MQa8uY55xqKSLdJACy1DDN9UEQWHAK115RsOptE0Cvw2lRUvAZ/e+lhIAYr1YJJz fWpAroUmWGqg7DeQogS/ZeW8krgpjweIIqIRf4ZXyw7kzpC5+ewp8k9kEQPMcsxI r8szg== 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=WbpUnkk1so8tCnNgiAjw5fxb6FAG9ecCCZi8gvoYN RU=; b=Zcn+pvI7wBpavIJdP+k6oitbgr57RQ52a40Q8+JboPlQA06KFqY/nZ4Db 2O1HpEMILAz3CpVV/LujUTgWJh39m0tDFcY155Vi1K62pHsYoUkFy+E6V7disFfK 2VMMQ5s6bH3Rq46O8N3In5LaGTHm3ywmhtiBX/845wNYVYDs+AwLDWx4QfkJlj3E sBlcaSasWBEtiPeCdoqPt7sj531FrbUqHFPYQ0uxGxQNK7ZxDDMXYPXWOxzWdQiv x0nHi7I85rAW1IBMwFnHlGc5tiNBdsSQJdUpHH43ZuHALsmXr6xm/t7kbHmZmDnz ZSIezb0JoO0auHfHfxItzQapYONHg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdefgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrgestgho ohhpvghrfidrihhnqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutdekrd ehuddruddtuddrleeknecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestgho ohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id E4FD330607B0; Wed, 15 Jan 2020 12:19:30 -0500 (EST) 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: <24095.13730.124469.943932@gro.dd.org> Date: Wed, 15 Jan 2020 12:19:27 -0500 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <580AF603-F1EE-4C4B-93D1-946C07239CCF@cooperw.in> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 17:19:37 -0000 > On Jan 15, 2020, at 10:54 AM, Dave Lawrence wrote: >=20 > Ted Lemon writes: >> Rather than just deleting this text, which I agree is probably not=20 >> what we want, how about fixing it? =20 >=20 > That's where I am on this. I like the proposal as a whole and just > think this little bit on the security properties needs tweaking. I may have been the one to originally propose this language to Tommy and = others, and I recognize that was a bit of an error. The formulation in = the charter text that Ben Schwartz circulated seems more workable (plus = dropping the =E2=80=9Cany=E2=80=9D before =E2=80=9Cmechanisms=E2=80=9D): "Where possible, mechanisms that specify exchange of information between = clients and resolvers should provide the security properties expected of = IETF protocols, e.g., confidentiality protection, integrity protection, = and authentication with strong work factor. Each specification must = clearly indicate under what circumstances and assumptions these = properties are or are not provided.=E2=80=9D I think this would be a good guidepost to have in the charter, and is = less prescriptive than the tweak offered by Ted Lemon. But from my POV = it=E2=80=99s just a nice-to-have if it=E2=80=99s not so controversial = that its inclusion prevents the charter from being approved. Alissa > I've > got to run at the moment though and apologize for not having a > concrete proposal for the tweak. >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Wed Jan 15 09:29:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28774120885 for ; Wed, 15 Jan 2020 09:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZWdVrdNGsFPV for ; Wed, 15 Jan 2020 09:28:47 -0800 (PST) Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 4893A1208AA for ; Wed, 15 Jan 2020 09:28:47 -0800 (PST) Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa4.dc.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id 00FHSh3H009433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 17:28:44 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 15 Jan 2020 09:28:40 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Wed, 15 Jan 2020 09:28:40 -0800 From: Paul Hoffman To: Ted Lemon CC: ADD Mailing list Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy7sS3dTn6q33TECqcNmmmuiki6fsbWiAgAAIXACAAAtVgA== Date: Wed, 15 Jan 2020 17:28:39 +0000 Message-ID: <6129ADF8-E55A-41CF-A193-0070636B223D@icann.org> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <85F15EAE-6933-451D-A04F-3DE2907603FB@fugue.com> In-Reply-To: <85F15EAE-6933-451D-A04F-3DE2907603FB@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_F9E3B914-4912-4A40-A265-3874A4C29F0E"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-15_02:, , signatures=0 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 17:28:52 -0000 --Apple-Mail=_F9E3B914-4912-4A40-A265-3874A4C29F0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 15, 2020, at 8:48 AM, Ted Lemon wrote: >=20 > On Jan 15, 2020, at 11:18 AM, Paul Hoffman = wrote: >> The first sentence is well-intentioned but does not usually lead to = useful text in documents. The second sentence assumes that there are = methods that can be cryptographically validated: as I said above, I do = not believe they exist. >=20 > Of course such mechanisms exist. The problem is that they can=E2=80=99= t happen without some explicit trust establishment mechanism, which = necessarily requires manual intervention. Fair point. They exist but they cannot be used in the Internet as we = know it. That's why I believe they are not worth mentioning in the WG = charter. > What I want to capture is that any mechanism that the ADD WG comes up = with that doesn=E2=80=99t have a trust establishment mechanism doesn=E2=80= =99t override a mechanism where trust has been established explicitly = unless there=E2=80=99s some specific reason why that=E2=80=99s the right = thing to do. E.g., Tommy I think mentioned, and this is a use case I = deal with regularly as well, that you might be connected to a network = that uses a split-dns configuration where if you query a public = resolver, you just won=E2=80=99t get an answer for some domain. I think = that there is a pretty strong motivation from some of the participants = to support a use case for CDNs; figuring out how to do this seems like = it would be very much worthwhile, even if such a mechanism doesn=E2=80=99t= come with an explicit trust relationship. >=20 > I would expect that a trust establishment mechanism based on the ANIMA = on-boarding process (IETF) or the Thread commissioning process (Thread = Group) would also be cryptographically verifiable, since devices = commissioned using either mechanism can in fact cryptographically = validate that they are connected to a particular network; it=E2=80=99s = not a big step past that to validating the resolver. =20 In both those models, I believe, an individual specifies a source of = trust and a public key for that source of trust. =46rom that point = forward, the source of trust can announce anything it wants; all that = remains to define is an announcement format and expected communications = paths. That seems fine. > If course, for a device that doesn=E2=80=99t have any such = configuration established, a simple DHCP mechanism or RA mechanism for = getting opportunistic security is still very much worth doing. Fully agree. > That said, I think it is in scope for the WG to talk about = configuration mechanism that require manual intervention and do = establish cryptographically verifiable trust. Do you disagree with = that? To me this seems like an important part of the problem space. I strongly disagree with the second part of the first sentence "and do = establish cryptographically verifiable trust", which is why I disagree = with the inclusion of text in the charter that hints that this WG has = any part in the setup of trust. In my view (which at least some others = seem to share), either you have cryptographic trust to a source already = set up (ANIMA, old skool secure DHCP, Some Vendor Says So, ...), or you = have none and whatever you hear on the network can only be trusted by = leap of faith. All proposals between those have historically led to = ratholes, and thus I would like to leave them out of the charter. --Paul Hoffman= --Apple-Mail=_F9E3B914-4912-4A40-A265-3874A4C29F0E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMTE1MTcyODM5WjAvBgkqhkiG9w0BCQQxIgQgDC1OZMxNMqDZdRn7tS6BDx+NfU0Q xe4Hil/dsS1R0rgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAIGHtXCodfkon2t+TjC097dKxBfDK3JMn9FJJf9tQkh+ YA/2w1l58E50yW3z8mUetRPN0RwfwTBpBA4C4dspyQxzbFpBIkSwUCl+HpcxZ7zTH6u/Z4fPSgvZ pXEKRbOrQnmd6jV1PnhXvD9GKwb4GDfS6V7gGkg9c1ZP7dsnhLsdt8UCB/6ghK99RuQGZjDtMEFh x/mCwmh+gxLF8/lOTQWqNhk0BovmuzxFQD6+IUqpTSwTFIy1fr0FJqlX+Aze/KmchthFrRvWkdOA 5/C0bxQVcfGXHbohb7d/ixpmhlpg6/NdvRHIqdh5PHnrhP163W3fUa+J13/+ecDrSV11+CcAAAAA AAA= --Apple-Mail=_F9E3B914-4912-4A40-A265-3874A4C29F0E-- From nobody Wed Jan 15 11:24:23 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2D9120915 for ; Wed, 15 Jan 2020 11:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 tdnIMwoPBMIR for ; Wed, 15 Jan 2020 11:24:16 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0: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 7A28B12090B for ; Wed, 15 Jan 2020 11:24:16 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id x5so15868194ila.6 for ; Wed, 15 Jan 2020 11:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kAdmPqEycsXQKiQJhW6p9MK/u/g57OU7mkJGyrSy8Fw=; b=QD90lVYew/l1hohWYyxXU94VfilkuLJG4aUGWhd1r7BYz5pPrreL2IzYFa58R8sW8z c38sBypxwPEiSnANlWnWHdx/99LlqEjVbPnwzTXkteCFN7PC42y9zaWwxP5at8zU9WUw yv1N2MgDWSotb+yWqqIdou+zGdFG1HQjfpFWqNcIACCeQGafEsBPOcYyIIgJS/7DfjoG ExNEs9QXWRzdIuZwY2+PU+Jg0Dq5YOJfvJzVzloN+UVZh/K3z1vn7xcAoC7pOE3HZNGY iy481Zr/lHUojjVJcvQYvZqvCoSsWpdrZuNREWNu+x0jYzDIUY+kENfpiJVqK77PoqLZ oNvg== 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=kAdmPqEycsXQKiQJhW6p9MK/u/g57OU7mkJGyrSy8Fw=; b=sbfXEztMTsnsksEzdSbvf9dkCsPBq8H3+AgFISGzY8GVB6bqlaQy5cHafApEqKuIkX FRmNoz0DXFQm4lHT9Ow6ypjPu5idxX5uvH0Q2IlqzTYLa4PO8tBPEJnz5EIr3TNWWjKv OyGA2ECjiKAgKyi5jzx59LO7WGUoR0HLROCZoTdqBi+a5sr+Evb0EBgkzjTOKvtGfyXX SzKTHktU9O1d10aceZHFAs7EKvxfkp78gzY0HOfQnjn5L6T0yhC6/X3a8WddnRVp9/kY hUpvlgsuvN6bbDY637O4V/CkJPvU2NfildcWsXizZwoPHnJ4oTPLnQG4u5n2KHhNBqV/ 7Tsg== X-Gm-Message-State: APjAAAVMrfyf5HhGl2vxEkIgnuDlXlgy5/nJ2bR6GRT678OdqGU41qIy VCxhtgUOVKClamqYeH7eghlo8evlVN6N9eY7jh8= X-Google-Smtp-Source: APXvYqxxXSng/RF8AKaIz34R7gvTyC65CIleTMYOcPsu1GWkIhqsTSeIZnw9HQzObEO/Z3dsc9uNXS3ZvQREqmIHhzQ= X-Received: by 2002:a92:5845:: with SMTP id m66mr45267ilb.257.1579116255787; Wed, 15 Jan 2020 11:24:15 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> In-Reply-To: <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> From: Rob Sayre Date: Wed, 15 Jan 2020 11:24:02 -0800 Message-ID: To: Ted Lemon Cc: Paul Hoffman , ADD Mailing list , Tommy Pauly Content-Type: multipart/alternative; boundary="0000000000007c40d2059c32a737" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 19:24:20 -0000 --0000000000007c40d2059c32a737 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 15, 2020 at 7:48 AM Ted Lemon wrote: > On Jan 15, 2020, at 10:13 AM, Paul Hoffman wrote: > > Any mechanisms that specify interactions between clients and > servers must provide the security properties expected of IETF > protocols, e.g., confidentiality protection, integrity protection, > and authentication with strong work factor. > > Any mechanism whose understanding of the network and network services > comes from interactions that were not cryptographically authenticated (such > as DHCP and RA) cannot meet those requirements. > > > Rather than just deleting this text, which I agree is probably not what we > want, how about fixing it? > It might help to understand how people are planning to deploy DoH/DoT on local networks. Right now, my DNS server is 192.168.86.1, and encrypted DNS seems designed to bypass it. thanks, Rob --0000000000007c40d2059c32a737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 7:48 AM Ted Lemon= <mellon@fugue.com> wrote:
On Jan 15, 2020, at 10= :13 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Any mechanism= s that specify interactions between clients and
servers must provide= the security properties expected of IETF
protocols, e.g., confident= iality protection, integrity protection,
and authentication with str= ong work factor.

Any mechanism whose underst= anding of the network and network services comes from interactions that wer= e not cryptographically authenticated (such as DHCP and RA) cannot meet tho= se requirements.

Rather than just d= eleting this text, which I agree is probably not what we want, how about fi= xing it?

It might help to under= stand how people are planning to deploy DoH/DoT on local networks. Right no= w, my DNS server is 192.168.86.1, and encrypted DNS seems designed to bypas= s it.

thanks,
Rob
=C2=A0
--0000000000007c40d2059c32a737-- From nobody Wed Jan 15 11:47:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523A21209B5 for ; Wed, 15 Jan 2020 11:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPchTmdUnsXa for ; Wed, 15 Jan 2020 11:47:38 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100046.outbound.protection.outlook.com [40.107.10.46]) (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 6C4EA120996 for ; Wed, 15 Jan 2020 11:47:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aq0EbyZZ5Ed4kZzlzAg+64SGzyUz8BbqxB/vbprEdMeCFjD+KyxQHdXzLJfAFbS/1+kpVnV5cH0215pjzokABmVlJlCOyib33FTpR6Htgv7f69Z3x1Hkvhp9MQAIM//asLwNEAusuYDc5bfacmwg3cW5SteNeXCTG2xjVCvgvufWIdDSiCSBDnDzNYEITQkn47G1Ab2I38uzgLhp9/1GPyoUMJepDk4GsfV6L4xYFG+EEOLhAzM/IKJOJqrSynlLjemA0KJwnW2Bg4OCBKdHS6RILVidik6EykBZ87FmPGgUb9tKdbA8qr59I7nRvWDPsgSNYulCIksxNmAI24c+JA== 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=X4NJ3enBh1ydG72lujaTec3tfpsXDYcwOwEz7UiNHUI=; b=DvYx+NfWHW7Ee/c+XHHKeotx2PJ9KWUplgTSV82BuCmmHHYILfUYpB5/H+LFist06gJ9QGlBZ8yhl7eNF9720tFPzevutmZjS3Mw/IZOFUdiENE0PPPMhccInsYmUCziylv6eY2K515nUa9G8vFzdWHCsKrCBdpsWqKUaKjaZeDffL/4ZZXa1vrIoIZDH4DgJiaXbs7L4ABtG+6ZnuYt6Z2bM7FXuH5tjuWbPZ0sdFmVHPsMV+FutiNZfL5db7CjpuDTaIO2ZJ7QhpmM4PXbYDwK8hU+UN4dJWIHCl9djEvzz3j7KNZ0Z+IoiaYUOWCMMWJt1yaZqRtSpcuVxf359Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X4NJ3enBh1ydG72lujaTec3tfpsXDYcwOwEz7UiNHUI=; b=GyvkSGNse5Z5/pa8tQzq/LFluSe2YEJZOofF6K38AfSYNpTTjUjIcgjBg3FsyLCrXuW+ZjGxfLfiRE4+VRy0t/P14WAwrXYdInmc6JL5Pa91uiyUrdK8Mwn2qtwnMT2RuvdyvzBqztsSvYpTHzJuRuBJVGcloaVzXEht19JjbP0= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1070.GBRP265.PROD.OUTLOOK.COM (20.176.145.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 19:47:35 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::c5ab:3a91:1095:e8af%5]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 19:47:35 +0000 From: Andrew Campling To: Rob Sayre CC: ADD Mailing list Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy9lqwC/nlKcMjUOTXypYWIN7UafsIFTA Date: Wed, 15 Jan 2020 19:47:35 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> 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=andrew.campling@419.consulting; x-originating-ip: [89.34.98.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 140a8e82-2190-42b3-e2d7-08d799f3c4dc x-ms-traffictypediagnostic: LO2P265MB1070: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(396003)(39830400003)(366004)(189003)(199004)(186003)(508600001)(33656002)(66556008)(66446008)(9686003)(52536014)(76116006)(55016002)(5660300002)(53546011)(6506007)(26005)(316002)(558084003)(81166006)(2906002)(4326008)(8936002)(64756008)(71200400001)(44832011)(8676002)(7696005)(86362001)(81156014)(6916009)(66946007)(66476007)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1070; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bKOLMpW+qFEHf6F1yyRZnPR5zM2CsniDhjTc3ZGHqc/MPBTderTuf3ZYXMdUNO9WLmouB0O+IPZkkjj5lDAVrkNtArUypcUHIZYyyLO2Axyz53FzXXdicpiBHtjb/kbZPGCAdVUei94fkmwctF0MCTXuOwHTFLnb492SqXu+QWoB5nSgQ6EovS18gNR5p77LqGybMf3MfmveBqMI0ofocDMDHtBjfr2I7EiyQsrCh45a94Mjk3XDk5P+9hIBm1jgZSOEMh9XhMx9dQSckeK7sFUmxjNZ7xnGb+SiRG+MxiSzH5YVgDTam6BwNqOsIi2vdQY2qR1muSTPkc4OKjKkScmQhb10c+HnbR0kQmiE8sfeKpw4J9Q84pzaOCfyo2XirXERx9N6F6Gxq3Y+dH5PSnurVciHfXlcav1K2CvQSZQq+WiPKFhMWlvcgXIyFhBRGDmLeoe7qO92BtLGR+9YPRi3Iij9+Jjw4xf15XAQxLg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB05730A944404EFD86DF99E8CC2370LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 140a8e82-2190-42b3-e2d7-08d799f3c4dc X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 19:47:35.4268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BD+EswdS0tRr6GZUI64Vu+4t+Y8TerFtcnfrsTYOMYF6QF7K3E+fvItLMSk2hAwbv05AuLXZci78Hna3LLdC7wLHzJ5+G8e8oJw20XW5NMM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1070 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 19:47:42 -0000 --_000_LO2P265MB05730A944404EFD86DF99E8CC2370LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gV2VkLCBKYW4gMTUsIDIwMjAgYXQgMTk6MjQgUm9iIFNheXJlIDxzYXlyZXJAZ21haWwuY29t PiB3cm90ZToNCj4gUmlnaHQgbm93LCBteSBETlMgc2VydmVyIGlzIDE5Mi4xNjguODYuMSwgYW5k IGVuY3J5cHRlZCBETlMgc2VlbXMgZGVzaWduZWQgdG8gYnlwYXNzIGl0Lg0KDQpBbHRob3VnaCBu b3QgY3JpdGljYWwgdG8gdGhlIGNvbnRlbnQgb2YgdGhlIGNoYXJ0ZXIsIEkgdGhpbmsgaXQgd291 bGQgYmUgaW50ZXJlc3RpbmcgaWYgeW91IGNvdWxkIGV4cGFuZCBvbiB0aGlzLg0KDQoNCkFuZHJl dw0KDQoNCg== --_000_LO2P265MB05730A944404EFD86DF99E8CC2370LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gMTUsIDIwMjAgYXQgMTk6MjQgPHNwYW4gbGFuZz0i RU4tVVMiPlJvYiBTYXlyZSAmbHQ7c2F5cmVyQGdtYWlsLmNvbSZndDsNCjwvc3Bhbj53cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IFJpZ2h0IG5vdywgbXkgRE5TIHNlcnZlciBpcyAxOTIuMTY4Ljg2LjEsIGFuZCBlbmNy eXB0ZWQgRE5TIHNlZW1zIGRlc2lnbmVkIHRvIGJ5cGFzcyBpdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx0aG91Z2ggbm90IGNyaXRpY2Fs IHRvIHRoZSBjb250ZW50IG9mIHRoZSBjaGFydGVyLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGludGVy ZXN0aW5nIGlmIHlvdSBjb3VsZCBleHBhbmQgb24gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48bzpwPiZuYnNwOzwvbzpwPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5kcmV3IDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_LO2P265MB05730A944404EFD86DF99E8CC2370LO2P265MB0573GBRP_-- From nobody Wed Jan 15 11:54:37 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA8120972 for ; Wed, 15 Jan 2020 11:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 RU7_271cDtE7 for ; Wed, 15 Jan 2020 11:54:35 -0800 (PST) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 0D6C012092D for ; Wed, 15 Jan 2020 11:54:35 -0800 (PST) Received: by mail-oi1-f182.google.com with SMTP id c16so16643653oic.3 for ; Wed, 15 Jan 2020 11:54:35 -0800 (PST) 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=urTg6boDzZAJ/4+Mqqesgn6FBJ2as9q8p3JZviGc5ZY=; b=NzD5Ywc37tYkPBTgnw505M52W1BeIyav8gvFOKZTaGYLjOJHUskt1gNjuoMDnvksPR 34is/flHLSZwNqEQR+gIMi7+O++SxeDNMYblryQRNBtuHRB8/Aje5if2m6/loraRDEse queq+nJiq8rRsBQD1k/CeLnxrgQ6O6Y7TAIQ1SVbg6/mQgizLtZ8XoUU1kvNc50L3YNr sfU9LMSep5o1YF/+Lvz3iJ4k/65RgdqsiSgwI2tJH/m8R6/qpDLSelfZnFGOi9QLgTKi iDNUFLaUST7qrIrDsOwmXssH42QE1v2TeawG3FVlXwmYUZksxBbAk9JEXF1trv78WcxL QzSw== X-Gm-Message-State: APjAAAUodnfMyVIO6tNgi6iMLnmcNZ8BpwMN9WDdIPxD32wXIJAJYISB znB7m6CxREwslgw3Nhlkw6mAWYKMnZn6tJWjXWQ= X-Google-Smtp-Source: APXvYqxUmfWGkDnca+XDPEQNiNXm27cQqRnguR3XEnHsVefv1/8NuynVv0f2x7VRqVxKkcb0ivaX0kjb8j43TYwEKfM= X-Received: by 2002:a05:6808:3c2:: with SMTP id o2mr1199315oie.145.1579118074257; Wed, 15 Jan 2020 11:54:34 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> In-Reply-To: <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> From: Barry Leiba Date: Wed, 15 Jan 2020 14:54:22 -0500 Message-ID: To: Ted Lemon Cc: Dave Lawrence , ADD Mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 19:54:36 -0000 I understand the interest in a statement such as this, but I don't really see a need for it: We have established needs for Security Considerations, we have Security ADs who will be checking for proper coverage, and we're most likely to include an assigned technical advisor from the Security Area when we establish the working group. So, while some sort of discussion in the charter might not be harmful, it doesn't seem necessary and seems sure to cause a lot of angst in getting agreement on the wording. Barry On Wed, Jan 15, 2020 at 11:19 AM Ted Lemon wrote: > > On Jan 15, 2020, at 10:54 AM, Dave Lawrence wrote: > > That's where I am on this. I like the proposal as a whole and just > > think this little bit on the security properties needs tweaking. I've > > got to run at the moment though and apologize for not having a > > concrete proposal for the tweak. > > In case it=E2=80=99s not obvious, this is what I was proposing for a twea= k: > > Any specification must include a clear and thorough discussion of the pri= vacy and security implications of using the method or methods it describes.= Methods where a mechanism that cannot be cryptographically validated for = integrity or which do not provide a cryptographically validatable trust est= ablishment mechanism will clearly describe the use case(s) in which such an= override is thought to be needed, should have a clear applicability statem= ent limiting the scope of the specification to those use case(s), and shoul= d clearly describe the risks and benefits of such a choice. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Wed Jan 15 12:00:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047B1120A5C for ; Wed, 15 Jan 2020 12:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0xWlBqSlp5lq for ; Wed, 15 Jan 2020 12:00:07 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A051209FF for ; Wed, 15 Jan 2020 12:00:06 -0800 (PST) Received: from tpw09926dag05e.domain1.systemhost.net (10.9.202.20) by BWP09926079.bt.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 15 Jan 2020 19:59:28 +0000 Received: from tpw09926dag08e.domain1.systemhost.net (10.9.202.35) by tpw09926dag05e.domain1.systemhost.net (10.9.202.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 15 Jan 2020 20:00:03 +0000 Received: from bwp09926080.bt.com (10.36.82.111) by tpw09926dag08e.domain1.systemhost.net (10.9.202.35) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 15 Jan 2020 20:00:03 +0000 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.59) by smtpe1.intersmtp.com (10.36.82.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 15 Jan 2020 19:59:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z9GjIOzJViuCxx5CjnpXJraqJJzUYofT7URbmv+R9/P3+Kp/XpVU5KNudXjxWL4bGEz5Hq9XblgK4aY/FyQCgKMQkN5jiKZrsbgPYSPlxtI00crUgrXaQhnuQzCJoOka1IEQd3QduYMckiFlLZfGQ943l12x9pbKEqxH99m2WwbxrVstcXvDj8uI4POzPt3xc0n3e8386iy7Gw94eDx2rmbZvvN2eY0qYTWZgmbX+fhrKyWMcYfKBe5fpmWkjVHpDETE4CMo990vixIx05Vlc5cmqOklsb+sqk0DvIuJKn5oKlOZVDyDtWsun9CPprTlIxaQ5UNdtS5o7lFHVX1HIA== 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=WF8OzCj0U8QuqDWnjWiICbdIM3Yi3C9JxUOYfiPyIIs=; b=obA6cI4J2G5hLnfxRnqJ90NAUrEx39SVOeIlO2m8/HBSDpmXzCXFkkWnpqQzVEcsk7ATGYFDljDjOzX0zkFoGFnBEVHaLI4VT25zMkCzFnSRMxxxvFEa3T6ofnGBrqJXn52kJnYcdfEz6YrHuKw+zYow6qqtrW907Sz6usbiuW/Un4Ze2Iqti/oeJlyj4TcVZVjADfVi7xS7Nx8pggmGAiJ1kvH5Hcm/4zTH+ThmiEv5o2wtm4NEyId19PthxqsPS7f7Q6EBNPEoXCfeiMMYRtVrXIT0hXml6hI9S4hWuyzUzLG9yqsGBcvYp/1ZMb878N+OgtZrChVnXPxj/wRqpw== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WF8OzCj0U8QuqDWnjWiICbdIM3Yi3C9JxUOYfiPyIIs=; b=aJ2oQ4Bl7yzk78NelZFiU2z/FpbubzCGXgrJ734MmlrgchNPLaPhFMoHetTK0gge0UYtbry3gXqJeA9WDavDXnZkggoDETzVI8mQM9UlDONJDO9EDPnyD0sz1npqWzqus64+95uke9Jzy1RRQ80pnw5Aqln4dF49L+rBxXzc3IE= Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM (20.176.158.15) by LO2P123MB1855.GBRP123.PROD.OUTLOOK.COM (20.176.157.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Wed, 15 Jan 2020 20:00:02 +0000 Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::6c1f:7fed:462a:e846]) by LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::6c1f:7fed:462a:e846%4]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 20:00:02 +0000 From: To: Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVyytfkI1lgBAHs0yl8SJFbjA7MKfr5goAgAA6ITA= Date: Wed, 15 Jan 2020 20:00:02 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <76785894-9B79-4EA7-83DA-22A589D9FDBA@piuha.net> In-Reply-To: <76785894-9B79-4EA7-83DA-22A589D9FDBA@piuha.net> 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: [213.205.240.245] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7999c4c-1eea-4d08-5b45-08d799f58251 x-ms-traffictypediagnostic: LO2P123MB1855: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(366004)(396003)(136003)(376002)(199004)(189003)(186003)(81166006)(8676002)(6916009)(7696005)(26005)(81156014)(8936002)(86362001)(33656002)(66556008)(478600001)(66946007)(55016002)(71200400001)(9686003)(15650500001)(316002)(6506007)(55236004)(2906002)(76116006)(64756008)(66446008)(52536014)(66476007)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB1855; H:LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: OXlACrlVgQaZd/LIwti3frCbtiVQ0Y6wv1nkdubpIum5wa6684TIeXn2sjj5UA1V66/DnTojeDq1j0GmRKPm/lXRPO+Z2SVjHonlJlik6NmnHkIWwFEAJyRSGw7xz+FqkbT+PCrbkj16PwQeXJpw1spbrUJ8423c7Or17buJvC4TkQSNI9YlUiMqEp5aE2afqrCKpzVO+14li8cTBnfYegTidaj02+kU8ujj5MANmh8r/Iejh+NIBm7dBbtIp3F9qMCQkBHbrFnmLTNiJ9ENOAKWjZ9KgWbiM1la73qjaISRgcsBp3FdEGTVI/SBDfORvkR+k9krs7fKKij9xJMkppnIindP5xycO17z00sYC0y6ikeTwPy8XOOavXKihhekKW0m/sAc22vr+6J/S2phtP9h+jirRmnh7cs1C8kz5jmKxfBgwrP0BxEFOL7KVuGu 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: b7999c4c-1eea-4d08-5b45-08d799f58251 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 20:00:02.8111 (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: KffucCnPaqb8ykMnDdPtY6un0Fs1He/feT1jamxohraJ4fKrbQrqGk0VWQkqsk4RHKAOIxD06MpLbacPemdzZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1855 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 20:00:14 -0000 Um9iJ3MgMTkyLjE2OC44Ni4xIHNlZW1zIHRvIGJlIG9uZSBwYXJ0aWN1bGFyIHVzZSBjYXNlLiBU aGUgd29ya2luZyBncm91cCBzaG91bGQgY29uc2lkZXIgYWxsIHVzZSBjYXNlcywgYW5kIEkgdGhp bmsgdGhpcyBjaGFydGVyIGRvZXMgdGhhdC4NCg0KSSBzdXBwb3J0IHRoZSBjcmVhdGlvbiBvZiBh IHdvcmtpbmcgZ3JvdXAgYmFzZWQgb24gaXQsIGlkZWFsbHkgYXMgYW1lbmRlZCBieSBKYXJpJ3Mg dHdlYWtzLiBUaGUgZmlyc3Qgb2YgdGhlc2Ugc2VlbXMgc2Vuc2libGUsIGFuZCBmb3IgdGhlIHNl Y29uZCBJIGNhbiBsaXZlIHdpdGggZWl0aGVyIHJlbW92YWwgb2YgdGhlIHNlY3VyaXR5IHBhcmFn cmFwaCwgb3IgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIGl0Lg0KDQpBdCB0aGUgZW5kIG9mIHRoZSBk YXkgd2UgYWxsIHdhbnQgdG8gbWFrZSBpdCBhcyBzZWN1cmUgYW5kIHJvYnVzdCBhcyBwb3NzaWJs ZSwgc28gdGhlIGNvbmNlbnN1cyBwcm9jZXNzIHdpbGwgc2VuZCBpdCBpbiB0aGF0IGRpcmVjdGlv biwgcmVnYXJkbGVzcyBvZiB0aGUgcHJlc2VuY2Ugb2YgYSBjaGFydGVyIHNlY3VyaXR5IHBhcmFn cmFwaC4gSSBhZ3JlZSB3aXRoIEJhcnJ5IHRoYXQgaXQgZG9lc24ndCBzZWVtIHRvIGJlIG5lZWRl ZC4NCg0KVGhlIG1haW4gcG9pbnQgaXMgd2Ugc2hvdWxkIHN0YXJ0IHRoaXMgd29yayBvbiBkaXNj b3ZlcnksIGNvbW11bmljYXRpb24gb2YgcmVzb2x2ZXIgaW5mbywgYW5kIHNlbGVjdGlvbiBwb3Nz aWJpbGl0aWVzLg0KDQpDaHJpcw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEFkZCA8YWRkLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBKYXJpIEFya2tvDQo+ IA0KPiAxLiBJIHRoaW5rIHRoZSB0aGlyZCBwYXJhZ3JhcGggd291bGQgYmVuZWZpdCBmcm9tIGFu IG9ic2VydmF0aW9uIHRoYXQgdGhlDQo+IGNob2ljZXMgaGF2ZSBpbXBsaWNhdGlvbnMuIEnigJlk IHN1Z2dlc3QgdGhpcyB0d2VhazoNCj4gT0xEOg0KPiBUaGVzZSBkZWNpc2lvbnMgY2FuIHZhcnkg YmFzZWQgb24gdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQsIGFuZCBhbHNvDQo+IGJhc2VkIG9uIHRo ZSBjb250ZW50IGFuZCBwdXJwb3NlIG9mIHRoZSBjbGllbnQgcXVlcmllcy4NCj4gTkVXOg0KPiBU aGVzZSBkZWNpc2lvbnMgY2FuIHZhcnkgYmFzZWQgb24gdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQs IGFuZCBhbHNvDQo+IGJhc2VkIG9uIHRoZSBjb250ZW50IGFuZCBwdXJwb3NlIG9mIHRoZSBjbGll bnQgcXVlcmllcy4gVGhlIGRlY2lzaW9ucyBtYXkNCj4gaGF2ZSBpbXBsaWNhdGlvbnMgb24gcmVh Y2hhYmlsaXR5LCBwcml2YWN5LCBhbmQgc28gb24uDQo+IA0KPiAyLiBBcyBub3RlZCwgdGhlIHBh cmFncmFwaCBvbiDigJxhbnkgbWVjaGFuaXNtc+KAnSBoYXMgc29tZSBpc3N1ZXMsIGFuZA0KPiBj b3VsZCBiZSBlaXRoZXIgcmVtb3ZlZCAoY2FuIGxpdmUgd2l0aCB0aGF0KSBvciBpbXByb3ZlZCAo Y2FuIGxpdmUgd2l0aCB0aGF0DQo+IGFzIHdlbGwsIGFzIGxvbmcgYXMgdGhlIGltcHJvdmVtZW50 IHByb2Nlc3MgdGVybWluYXRlc+KApikNCg0K From nobody Wed Jan 15 12:03:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C75120A19 for ; Wed, 15 Jan 2020 12:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Zeo3ONmI44V3 for ; Wed, 15 Jan 2020 12:03:22 -0800 (PST) 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 DA22B1209F6 for ; Wed, 15 Jan 2020 12:03:21 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id n11so19161067iom.9 for ; Wed, 15 Jan 2020 12:03:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y5tJbKm0xKFtQrCvmAOtlLcwSY2XX6d6G0RsYUq+kx4=; b=qhLmNixlDC2u+ofAsjqWZuc9opRjc4fsnpWTFjuo9hb/cjK7NrZszQgF8wLoG2+wbJ pfK9Jb6TdIknRk5bq6U4thNhFVmu0H99HvdBAwlwjaJWAz4D2J/P/fsRrv3GHAHW+w1A BSq69FP4HZf68dob/BHgqDo++H1r05nrGhQKUxhWFIHON3Pxp1s3A5IgmuKh1oSOK4yb Zcp/MHv/1VLH2L3dTF41+Sx3jpZgBUsvSCdrVWnp4Ta15+klwQXfu+KlgNOzds3nMed5 XrolZaZoQxMH693p/lh9GiWkcwDjGVbct7/CWZ8gnPLVqndsZ9IWpcC9gQhFnJgDjuex /wxA== 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=y5tJbKm0xKFtQrCvmAOtlLcwSY2XX6d6G0RsYUq+kx4=; b=eMOIxneDRnQNR8nZbK7VIVd18z6Q6ip8QbpR4+4lAAgtPwK78/20hfNJz/xOFSXvVe j4jPB8gYdY9HmnJBEoodHz+a3ubpEptOS59qBp7o5JCDBkd06nCGfh8LCZuzDw58hv7C Z8d9KsA7dqFjsJpmy5gw2ucd9yst0K1BwrdxZBlZsaM6EKuR/pxcqFwTCuhrmJ96Kms8 QqgWuvZ3pAm86u5mNLrRV2yHLPDKdyhenYYY4VULHn9yv2GksI6GXKPGoJR88eLfzWSA BC07rF7oTSJ67oS1Kc5T1r6zwP/bX5PsKWiFmrhSzw7ImRMQcCrolSbGyVCTw+gc0LwM JcLQ== X-Gm-Message-State: APjAAAWL9O548LNpkDgEaTojGGV2fkDPndSbVA18zb6S57yiDboYLGHj JFED5K0MAVgPduOH7l9upM/WOR5aWpa5V2OnUs7cqF+H9C0= X-Google-Smtp-Source: APXvYqyxQUlF4cBR7ROaTB9+Hecijzpum6qGDZVA+5aVdVkHtgRsS+H/z8dNfOMBGsaHIptIeKqA+zI9PUSTxv5tHZg= X-Received: by 2002:a6b:ec08:: with SMTP id c8mr23399907ioh.257.1579118600608; Wed, 15 Jan 2020 12:03:20 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> In-Reply-To: From: Rob Sayre Date: Wed, 15 Jan 2020 12:03:07 -0800 Message-ID: To: Andrew Campling Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000003f621a059c3333f2" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 20:03:27 -0000 --0000000000003f621a059c3333f2 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling wrote: > On Wed, Jan 15, 2020 at 19:24 Rob Sayre wrote: > > > Right now, my DNS server is 192.168.86.1, and encrypted DNS seems > designed to bypass it. > Well, a lot of networking products (both consumer and corporate) have an unencrypted DNS server on a private IP. I was wondering how the certificates would be constructed if they wished to offer DoH or DoT. I know public services are able to get certificates with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering how private networks will offer encrypted DNS, and whether the debate around the security considerations is important. thanks, Rob [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6 --0000000000003f621a059c3333f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 11:47 AM Andrew C= ampling <andrew.campling@419.consulting> wrote:

On Wed, Jan 15, 2020 at 19:24 R= ob Sayre <sayrer@g= mail.com> wrote:

> Right now, my DNS server is 192.168.86.1, and e= ncrypted DNS seems designed to bypass it.

=

Well, a lot of networking products (both c= onsumer and corporate) have an unencrypted DNS server on a private IP.

I was wondering how the certificates would be construc= ted if they wished to offer DoH or DoT. I know public services are able to = get certificates with SAN[1] extensions containing public IPs (e.g. the Clo= udflare cert for 1.1.1.1). That doesn't seem to make sense for private = IPs, so I'm wondering how private networks will offer encrypted DNS, an= d whether the debate around the security considerations is important.
=

thanks,
Rob


<= /div> --0000000000003f621a059c3333f2-- From nobody Wed Jan 15 12:49:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE7B12089C for ; Wed, 15 Jan 2020 12:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 2IDAW9K1hgCl for ; Wed, 15 Jan 2020 12:49:42 -0800 (PST) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 DDC9D120288 for ; Wed, 15 Jan 2020 12:49:41 -0800 (PST) Received: by mail-vk1-xa32.google.com with SMTP id t129so5118816vkg.6 for ; Wed, 15 Jan 2020 12:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TGACBXAbFTJ+/tGX+m9yhUd9i+//C9g/pVFuTpaHFBc=; b=Fft3ztu1QSyfUTZoXIP+bJxEnruB8dSvdxFpp+/ijIL5IV8Q8hew30WtMXX5CJlxdL 61mhrJ2G7HeKtvLqkxOZ3FNV80K8WALlg9SHGylHlQ1iWWnHgVA3xxLz3MukAcRQCDep mQmzLy4BafJCGMeZMwcD5X6Dhspr1Tu9yJBM3jsciNUFKkbCr8DcaKtSHDrjTL/oAGW5 IaLyMERLn9D7cEycaXzQMfLrfNOitWjIzN+4LAC92MBiVKXob1qIS/apRqJdnKuOd8yz T9WERTUPshlsGvYR4xg2qJ/eGj9ce1I66fWrzI2HyAXd9XFHWRlROXB75qFbORxFwZ6o FtFw== 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=TGACBXAbFTJ+/tGX+m9yhUd9i+//C9g/pVFuTpaHFBc=; b=dYmpdFnPEizP6nPZ+JavGrxvLIg5PMqtysDbV9ZOYRwHGjitF5CesD/XgJMa9EdmsK hgAio1YblWokooMoOdhmw6em11ZyqK9SUDtKga0qwcPu2Y51bLZxuSGfnf7SsSTe0JP0 1g1/htZgW5kGm5hj6HqXOGwGxdtPvKmxRhXI1wn5BICM5g1uRPG6/CM7xouk0uEcdUhD cvyJD7GyB1qV4NbRDEDTKFxzb6Ol0laWoEusYjWQAXgEmdjwdFq/n2Ck9JV6V1cnT2BS C76Q5QZpMS4uQp1eWXkME6O9NO4mSM3A955Tfq7jPgZzNag9JEK4qKTr8vkzqrm3DjOx gN2A== X-Gm-Message-State: APjAAAU1PEZPz5BexN0vbkt1frF40lDP8kMPKXEnFy2Q4mnEfeCMOKbH I+cSVI41xrenHDho7STBIWP/BMRH/30yUrrP6fs= X-Google-Smtp-Source: APXvYqxPR8AajHF1YlXqQ067Xgblfe8sj258gqRvkLzzZXkDfDdpgEpokVKyj5NtVzQfzlqJkom6Vo4Ho2BUO3z6TgM= X-Received: by 2002:a1f:73c6:: with SMTP id o189mr16124505vkc.60.1579121380863; Wed, 15 Jan 2020 12:49:40 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> In-Reply-To: From: Brian Dickson Date: Wed, 15 Jan 2020 12:49:29 -0800 Message-ID: To: Rob Sayre Cc: Andrew Campling , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f6b673059c33d8c7" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 20:49:43 -0000 --000000000000f6b673059c33d8c7 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 15, 2020 at 12:03 PM Rob Sayre wrote: > On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling > wrote: > >> On Wed, Jan 15, 2020 at 19:24 Rob Sayre wrote: >> >> > Right now, my DNS server is 192.168.86.1, and encrypted DNS seems >> designed to bypass it. >> > > Well, a lot of networking products (both consumer and corporate) have an > unencrypted DNS server on a private IP. > > I was wondering how the certificates would be constructed if they wished > to offer DoH or DoT. I know public services are able to get certificates > with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for > 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering > how private networks will offer encrypted DNS, and whether the debate > around the security considerations is important. > > Certificates can be self-signed. Self-signed certificates' fingerprints can be published in any corresponding DNS zone as TLSA records with the right subtype (2 or 3) that does not require PKI. Names for the DNS zones, certificates, and resolvers' host names can be from private-use portions of the namespace (such as has been proposed for use in the reserved portion of ISO 2-letter codes, like .zz). The client security can then be reduced to learning or distributing DNSSEC trust anchors for resolvers, including possibly doing "trust on first use" methods and well-known names. I.e. client queries well-known name for a pointer to the resolver's own name, along with a corresponding trust anchor for that name (name of a DNS zone). Once the trust anchor is available, everything else can bootstrap from that, including TLSA records (which give TLS fingerprints for certificates, which would be self-signed and validated without PKI, using the TLSA mechanisms.) I'm doing a proof of concept on this as we speak. Brian --000000000000f6b673059c33d8c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 15, 2020 at 12:03 PM Rob = Sayre <sayrer@gmail.com> wrot= e:
On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling <a= ndrew.campling@419.consulting> wrote:

On Wed, Jan 15, 2020 at 19:24 R= ob Sayre <sayrer@g= mail.com> wrote:

> Right now, my DNS server is 192.168.86.1, and e= ncrypted DNS seems designed to bypass it.

=

Well, a lot of networking products (both c= onsumer and corporate) have an unencrypted DNS server on a private IP.

I was wondering how the certificates would be construc= ted if they wished to offer DoH or DoT. I know public services are able to = get certificates with SAN[1] extensions containing public IPs (e.g. the Clo= udflare cert for 1.1.1.1). That doesn't seem to make sense for private = IPs, so I'm wondering how private networks will offer encrypted DNS, an= d whether the debate around the security considerations is important.
=


Certificates ca= n be self-signed.
Self-signed certificates' fingerprints can = be published in any corresponding DNS zone as TLSA records with the right s= ubtype (2 or 3) that does not require PKI.=C2=A0
Names for the DN= S zones, certificates, and resolvers' host names can be from private-us= e portions of the namespace (such as has been proposed for use in the reser= ved portion of ISO 2-letter codes, like .zz).
The client security= can then be reduced to learning or distributing DNSSEC trust anchors for r= esolvers, including possibly doing "trust on first use" methods a= nd well-known names.
I.e. client queries well-known name for a po= inter to the resolver's own name, along with a corresponding trust anch= or for that name (name of a DNS zone).
Once the trust anchor is a= vailable, everything else can bootstrap from that, including TLSA records (= which give TLS fingerprints for certificates, which would be self-signed an= d validated without PKI, using the TLSA mechanisms.)

I'm doing a proof of concept on this as we speak.

Brian
--000000000000f6b673059c33d8c7-- From nobody Wed Jan 15 13:00:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1395120911 for ; Wed, 15 Jan 2020 13:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 mwlJlT1MpzLl for ; Wed, 15 Jan 2020 13:00:48 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 06D6B12090B for ; Wed, 15 Jan 2020 13:00:48 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00FKtUnl040715; Wed, 15 Jan 2020 16:00:45 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2xj4y9s3ay-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 16:00:44 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00FL0fjf031851; Wed, 15 Jan 2020 16:00:43 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00FL0ZJE031416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jan 2020 16:00:36 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id DE936400B576; Wed, 15 Jan 2020 21:00:35 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30488.vci.att.com (Service) with ESMTPS id B0AA7400B573; Wed, 15 Jan 2020 21:00:35 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.148]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Wed, 15 Jan 2020 16:00:33 -0500 From: "STARK, BARBARA H" To: "'Rob Sayre'" , "'Andrew Campling'" CC: "'ADD Mailing list'" Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy9lrH/Jj4q+ZTEW79nweBNTbH6fsdWOAgAAEV4D//7eF0A== Date: Wed, 15 Jan 2020 21:00:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.79.220] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611537457D1GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-15_03:2020-01-15, 2020-01-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 clxscore=1015 suspectscore=0 adultscore=0 mlxscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001150158 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 21:00:53 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611537457D1GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBXZWQsIEphbiAxNSwgMjAyMCBhdCAxMTo0NyBBTSBBbmRyZXcgQ2FtcGxpbmcgPGFuZHJl dy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZzxtYWlsdG86YW5kcmV3LmNhbXBsaW5nQDQxOS5jb25z dWx0aW5nPj4gd3JvdGU6DQpPbiBXZWQsIEphbiAxNSwgMjAyMCBhdCAxOToyNCBSb2IgU2F5cmUg PHNheXJlckBnbWFpbC5jb208bWFpbHRvOnNheXJlckBnbWFpbC5jb20+PiB3cm90ZToNCj4gUmln aHQgbm93LCBteSBETlMgc2VydmVyIGlzIDE5Mi4xNjguODYuMSwgYW5kIGVuY3J5cHRlZCBETlMg c2VlbXMgZGVzaWduZWQgdG8gYnlwYXNzIGl0Lg0KDQpXZWxsLCBhIGxvdCBvZiBuZXR3b3JraW5n IHByb2R1Y3RzIChib3RoIGNvbnN1bWVyIGFuZCBjb3Jwb3JhdGUpIGhhdmUgYW4gdW5lbmNyeXB0 ZWQgRE5TIHNlcnZlciBvbiBhIHByaXZhdGUgSVAuDQoNCkkgd2FzIHdvbmRlcmluZyBob3cgdGhl IGNlcnRpZmljYXRlcyB3b3VsZCBiZSBjb25zdHJ1Y3RlZCBpZiB0aGV5IHdpc2hlZCB0byBvZmZl ciBEb0ggb3IgRG9ULiBJIGtub3cgcHVibGljIHNlcnZpY2VzIGFyZSBhYmxlIHRvIGdldCBjZXJ0 aWZpY2F0ZXMgd2l0aCBTQU5bMV0gZXh0ZW5zaW9ucyBjb250YWluaW5nIHB1YmxpYyBJUHMgKGUu Zy4gdGhlIENsb3VkZmxhcmUgY2VydCBmb3IgMS4xLjEuMSkuIFRoYXQgZG9lc24ndCBzZWVtIHRv IG1ha2Ugc2Vuc2UgZm9yIHByaXZhdGUgSVBzLCBzbyBJJ20gd29uZGVyaW5nIGhvdyBwcml2YXRl IG5ldHdvcmtzIHdpbGwgb2ZmZXIgZW5jcnlwdGVkIEROUywgYW5kIHdoZXRoZXIgdGhlIGRlYmF0 ZSBhcm91bmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGltcG9ydGFudC4NCg0KdGhh bmtzLA0KUm9iDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI4MCNzZWN0 aW9uLTQuMi4xLjY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzUyODAtMjNzZWN0aW9uLTJENC4yLjEuNiZk PUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9n Jm09OF95dnYxaWwzemV3akd5N1E0UzRPdFFpdG5tQVNQdmpGNkxhX1RESF82VSZzPURJQnlaZVpU Ym5WUXotYmhnZTNvVkZ2RHpZSlRIS2RndWVNMF96LThXN3MmZT0+DQoNCjxiaHM+IERpc2N1c3Np b25zIEnigJl2ZSBoYWQgd2l0aCBwZW9wbGUgc28gZmFyIGhhdmUgYmVlbiBhbG9uZyB0aGUgbGlu ZXMgb2YgKDEpIHdl4oCZcmUgbm90IGF3YXJlIG9mIGFueSB1c2VyLWZyaWVuZGx5L2Vhc3kgd2F5 IHRvIGdldCBhIGNlcnRpZmljYXRlIGludG8gY29uc3VtZXIgcm91dGVycyB0aGF0IHdpbGwgYmUg b2vigJllZCBieSBhIENBIGluIGJyb3dzZXJz4oCZIHRydXN0IHN0b3JlcywgKDIpIHRoZSB1c2Vy IGV4cGVyaWVuY2Ugb2YgZG9pbmcgaHR0cHMgdG8gYSBjb25zdW1lciByb3V0ZXIgZnJvbSBhIGJy b3dzZXIgaXMgcHJldHR5IGhvcnJpYmxlIGFuZCBzY2FyeSwgKDMpIHNvbWUgb2YgdGhlc2Ugcm91 dGVycyAoZS5nLiwgTmV0Z2VhcikgZG9u4oCZdCBldmVuIGFsbG93IHVzZXJzIHRvIGNoYW5nZSB3 aGF0IHRoZSByb3V0ZXIgc2VuZHMgaW4gREhDUC9SQSAoaXTigJlzIGFsd2F5cyB0aGUgcm91dGVy 4oCZcyBwcml2YXRlIElQIGFkZHJlc3M7IGJ1dCB0aGUgdXNlciBjYW4gY2hhbmdlIHdoYXQgcmVj dXJzaXZlIHJlc29sdmVyIHRoZSByb3V0ZXIgdGhlbiB1c2VzKSwgYW5kICg0KSBtYW55IHBlb3Bs ZSBhcmUgdW5jb252aW5jZWQgdGhhdCB0aGUgdGhyZWF0IG9mIGNvbXByb21pc2UgaW5zaWRlIHRo ZSBob21lIG5ldHdvcmsgaXMgd29ydGggdGhlIGVmZm9ydCBhbmQgbmVnYXRpdmUgdXNlciBleHBl cmllbmNlLjwvYmhzPg0K --_000_2D09D61DDFA73D4C884805CC7865E611537457D1GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEph biAxNSwgMjAyMCBhdCAxMTo0NyBBTSBBbmRyZXcgQ2FtcGxpbmcgJmx0OzxhIGhyZWY9Im1haWx0 bzphbmRyZXcuY2FtcGxpbmdANDE5LmNvbnN1bHRpbmciPmFuZHJldy5jYW1wbGluZ0A0MTkuY29u c3VsdGluZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBXZWQsIEphbiAxNSwgMjAyMCBhdCAxOToyNA0KPC9z cGFuPlJvYiBTYXlyZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNheXJlckBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5zYXlyZXJAZ21haWwuY29tPC9hPiZndDsNCjxzcGFuIGxhbmc9IkVOLUdCIj53 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jmd0OyBSaWdodCBub3csIG15IERO UyBzZXJ2ZXIgaXMgMTkyLjE2OC44Ni4xLCBhbmQgZW5jcnlwdGVkIEROUyBzZWVtcyBkZXNpZ25l ZCB0byBieXBhc3MgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlbGwsIGEgbG90IG9mIG5ldHdvcmtpbmcgcHJvZHVjdHMgKGJvdGggY29uc3Vt ZXIgYW5kIGNvcnBvcmF0ZSkgaGF2ZSBhbiB1bmVuY3J5cHRlZCBETlMgc2VydmVyIG9uIGEgcHJp dmF0ZSBJUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB3YXMgd29uZGVyaW5nIGhvdyB0aGUgY2VydGlmaWNhdGVzIHdvdWxkIGJlIGNvbnN0 cnVjdGVkIGlmIHRoZXkgd2lzaGVkIHRvIG9mZmVyIERvSCBvciBEb1QuIEkga25vdyBwdWJsaWMg c2VydmljZXMgYXJlIGFibGUgdG8gZ2V0IGNlcnRpZmljYXRlcyB3aXRoIFNBTlsxXSBleHRlbnNp b25zIGNvbnRhaW5pbmcgcHVibGljIElQcyAoZS5nLiB0aGUgQ2xvdWRmbGFyZSBjZXJ0IGZvciAx LjEuMS4xKS4gVGhhdA0KIGRvZXNuJ3Qgc2VlbSB0byBtYWtlIHNlbnNlIGZvciBwcml2YXRlIElQ cywgc28gSSdtIHdvbmRlcmluZyBob3cgcHJpdmF0ZSBuZXR3b3JrcyB3aWxsIG9mZmVyIGVuY3J5 cHRlZCBETlMsIGFuZCB3aGV0aGVyIHRoZSBkZWJhdGUgYXJvdW5kIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBpcyBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJzcDs8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0 bWxfcmZjNTI4MC0yM3NlY3Rpb24tMkQ0LjIuMS42JmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85 X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209OF95dnYx aWwzemV3akd5N1E0UzRPdFFpdG5tQVNQdmpGNkxhX1RESF82VSZhbXA7cz1ESUJ5WmVaVGJuVlF6 LWJoZ2Uzb1ZGdkR6WUpUSEtkZ3VlTTBfei04VzdzJmFtcDtlPSI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzUyODAjc2VjdGlvbi00LjIuMS42PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7YmhzJmd0OyBEaXNjdXNzaW9ucyBJ4oCZdmUgaGFkIHdp dGggcGVvcGxlIHNvIGZhciBoYXZlIGJlZW4gYWxvbmcgdGhlIGxpbmVzIG9mICgxKSB3ZeKAmXJl IG5vdCBhd2FyZSBvZiBhbnkgdXNlci1mcmllbmRseS9lYXN5IHdheSB0byBnZXQgYSBjZXJ0aWZp Y2F0ZSBpbnRvIGNvbnN1bWVyIHJvdXRlcnMgdGhhdCB3aWxsIGJlIG9r4oCZZWQgYnkgYSBDQSBp biBicm93c2Vyc+KAmSB0cnVzdCBzdG9yZXMsICgyKSB0aGUgdXNlciBleHBlcmllbmNlDQogb2Yg ZG9pbmcgaHR0cHMgdG8gYSBjb25zdW1lciByb3V0ZXIgZnJvbSBhIGJyb3dzZXIgaXMgcHJldHR5 IGhvcnJpYmxlIGFuZCBzY2FyeSwgKDMpIHNvbWUgb2YgdGhlc2Ugcm91dGVycyAoZS5nLiwgTmV0 Z2VhcikgZG9u4oCZdCBldmVuIGFsbG93IHVzZXJzIHRvIGNoYW5nZSB3aGF0IHRoZSByb3V0ZXIg c2VuZHMgaW4gREhDUC9SQSAoaXTigJlzIGFsd2F5cyB0aGUgcm91dGVy4oCZcyBwcml2YXRlIElQ IGFkZHJlc3M7IGJ1dCB0aGUgdXNlciBjYW4gY2hhbmdlDQogd2hhdCByZWN1cnNpdmUgcmVzb2x2 ZXIgdGhlIHJvdXRlciB0aGVuIHVzZXMpLCBhbmQgKDQpIG1hbnkgcGVvcGxlIGFyZSB1bmNvbnZp bmNlZCB0aGF0IHRoZSB0aHJlYXQgb2YgY29tcHJvbWlzZSBpbnNpZGUgdGhlIGhvbWUgbmV0d29y ayBpcyB3b3J0aCB0aGUgZWZmb3J0IGFuZCBuZWdhdGl2ZSB1c2VyIGV4cGVyaWVuY2UuJmx0Oy9i aHMmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E611537457D1GAALPA1MSGUSRBF_-- From nobody Wed Jan 15 13:25:26 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EA120993 for ; Wed, 15 Jan 2020 13:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 f-NjeL5hk0JE for ; Wed, 15 Jan 2020 13:25:20 -0800 (PST) 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 0DBF312098E for ; Wed, 15 Jan 2020 13:25:20 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id d71so17198785qkc.0 for ; Wed, 15 Jan 2020 13:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YJmMs+oKsDtrDn79xFKtnDV3yJ3v99sNlKNlelYq4VU=; b=WjfQyUnNJF3/HaCgojOj3/aFCFm8wxKAk1K1zt3ei+Zs2PGDD8TU3y5LFhL/roez1P zR64xqCgT/1U2OQkTpw92Pxz5Qr9BWuL381QcrFmLhlelRy8Hdy26P9Ro3tDweRly9gp p1ApqNRN71UyjwCLIowosEYM8D/MY+PC6AsXMloBHOBAtkQDH+0TicSY6vJ8ig5ZGhII hVIfjP9mtRg1BWipzFuF0aRG6b5udqZADmOp+L0ULIXGGq8f4FYPjCDy4LZbLCBx+3BO VVdBP/siMjvRbF8MHt4V4mJVT9OHxn/53Bu6cbTH3+w32UQmx74rUIEnzBQ7BfOpXOhZ O+Kg== 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=YJmMs+oKsDtrDn79xFKtnDV3yJ3v99sNlKNlelYq4VU=; b=lBBpMqVSNR/Qlhuk/S3/jnse+GCnBXwQPNnS/16kvQ10QaB0PEv80Tb1tRmTr0oF8x 613/+pkOHDqCDQsbYvUD2CMSw2Hhkh1wdWJCF0qgw9S0pO/3dgg7jJVGArj9tGRt9l0b KEmfuMHN6UoJJLyfxCiB8RL06lBPZWQhnEFvCZBuGFihBseASHkAZijEEo0c2JJM8sBi g3t64VUnNoe/wgyYjG2ImjVp0mhmYacpKwbUREZV0X4LeARqtk1iUbdhRPLaGWUeXN+2 RCxH3pqPq9A8EJ3e2GBMXJ1+VpTPvtxWrPuTrXVH8TaGPM7NpevSCPx8n3mTa1oqWTyv LbJA== X-Gm-Message-State: APjAAAVtBdJ1qXNZgcaLfv+bBmuAEUiywY9oS+fjcVUKTYhNu/GsYL9+ B5vuf/8KME6pGBgWCJuk4UnOVjjBR+rtRg== X-Google-Smtp-Source: APXvYqx8irQKotykncwgZRC6qrU/dsAZc9Wf4soAUFdjHbqAgP/qKh8wiuVnlH7eUc0BI5GhxHUD0g== X-Received: by 2002:ae9:f714:: with SMTP id s20mr29345778qkg.236.1579123519112; Wed, 15 Jan 2020 13:25:19 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id 200sm9198554qkn.79.2020.01.15.13.25.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 13:25:18 -0800 (PST) From: Ted Lemon Message-Id: <7368AE4B-1BA2-4BFE-97AE-D0523D3B72A5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_78D2316F-E9F6-47B5-8789-D87B70259B13" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 15 Jan 2020 16:25:16 -0500 In-Reply-To: Cc: Dave Lawrence , ADD Mailing list To: Barry Leiba References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 21:25:25 -0000 --Apple-Mail=_78D2316F-E9F6-47B5-8789-D87B70259B13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 2:54 PM, Barry Leiba = wrote: > I understand the interest in a statement such as this, but I don't > really see a need for it: We have established needs for Security > Considerations, we have Security ADs who will be checking for proper > coverage, and we're most likely to include an assigned technical > advisor from the Security Area when we establish the working group. At present there are no /IETF/ specifications that talk about trust = relationships between hosts and resolvers for DoH or DoT. So from the = IETF perspective, this is a green-field working group charter. The = working group could start out by doing a specification that defines a = DHCP option, or an RA option, which could be MTI. The IESG would have = no particular reason to reject this proposal. This as-yet-to-be-named = security advisor might or might not consider this to be a problem. If you consider it to be the case that the working group should be doing = this anyway, then there can=E2=80=99t possibly be any harm in putting = this in the charter. If we put it in the charter, then when the last = call comes along, we can point to the charter and say =E2=80=9Cthis = isn=E2=80=99t in the charter.=E2=80=9D That seems like a good thing to = be able to do, and seems like it would cause no harm if what you are = saying is true. That said, I have not actually heard anybody other than you and Paul = object to the new language I proposed, and Paul=E2=80=99s objection = appears to be semantic rather than functional. So where is this pushback coming from? --Apple-Mail=_78D2316F-E9F6-47B5-8789-D87B70259B13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 15, 2020, at 2:54 PM, Barry Leiba <barryleiba@computer.org> wrote:
I understand the interest in a statement such as this, but I = don't
really see a need for = it: We have established needs for Security
Considerations, we have Security ADs who will be checking for = proper
coverage, and we're = most likely to include an assigned technical
advisor from the = Security Area when we establish the working = group.

At = present there are no /IETF/ specifications that talk about trust = relationships between hosts and resolvers for DoH or DoT.   So from = the IETF perspective, this is a green-field working group charter. =   The working group could start out by doing a specification that = defines a DHCP option, or an RA option, which could be MTI.  The = IESG would have no particular reason to reject this proposal.  This = as-yet-to-be-named security advisor might or might not consider this to = be a problem.

If= you consider it to be the case that the working group should be doing = this anyway, then there can=E2=80=99t possibly be any harm in putting = this in the charter.  If we put it in the charter, then when the = last call comes along, we can point to the charter and say =E2=80=9Cthis = isn=E2=80=99t in the charter.=E2=80=9D  That seems like a good = thing to be able to do, and seems like it would cause no harm if what = you are saying is true.

That said, I have not actually heard anybody other than you = and Paul object to the new language I proposed, and Paul=E2=80=99s = objection appears to be semantic rather than functional.

So where is this = pushback coming from?

= --Apple-Mail=_78D2316F-E9F6-47B5-8789-D87B70259B13-- From nobody Wed Jan 15 13:26:27 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA3C12098E for ; Wed, 15 Jan 2020 13:26:25 -0800 (PST) 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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=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 P2m_MwXeGwqx for ; Wed, 15 Jan 2020 13:26:21 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 D4264120A4C for ; Wed, 15 Jan 2020 13:26:20 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id w67so5160132vkf.1 for ; Wed, 15 Jan 2020 13:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5SDw3ixueETGQzWBWJFG3runxkZ6oyTQBVPOQ1Uaon8=; b=b6cC+MaWXvqhbXmZi2ykux15xtB5PZEzNNva/CiJII55aQe5OcjNOvy0VcdmdlMBQt r2JHunAT3u6io4tfibCU2LSpbc3pnwHSxm13mfcsuZCrDxo6/jqWW0GvibiPjnZu1g+Y TMfMnIOHDgRoWfdhgn9wMOp8EQQaFp+5W5v+fUwTXE1UR9OfB/r9pufSg94lHaZVTPJ+ AV8tCq97DVVhgEz4KTvFlVvZ0DTglujEMejr+yrSgt34whD5SCphV9PUnxdeLsSqJmov I6R6ujCTgayfsGL+U0cem3cVM47sygKRAKMpBa/0a5eii0DTDNOjGRtmw3vh1JXql7Kg Kowg== 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=5SDw3ixueETGQzWBWJFG3runxkZ6oyTQBVPOQ1Uaon8=; b=OsHx6aUyfhKLahxonJWsEYBuqY52vxwnH3TL3ex6Ad+cbrTudDVG2ts4P08kynruI8 UdFTyuzQJa+p71Nt6BIkoIoum3hgxqwivhCPW3gFGoaMPQiGbUvPFe4sj5baEVJHcdF5 YJoBIam15U7lywc5cOjxagunafjOV7UXrTbCw46o7xcv9Mg1BgDgf/d1pBMcd0UtBTcs J7ufAQ10Ot9tl9Tu7FiKMeuRxLIVV6zw/eeagxBa/pY8ttBjjEYp8CorQl1L3NCMjNYF +jEjshcTl/q2nTOBvgc5b+vVpy+PGhEuiDA7QTD9RQzxa2jYSyLa51dhZylcSwZ4ryp+ Ygng== X-Gm-Message-State: APjAAAWGMEMemb7knuMUNQzODoWSHw/6LvsSn/QWxJlttnmedg1Vh4KL 9KiVjcf7CJ3fle8E+J/HcQzhsT98xhX3ljn4PdQ= X-Google-Smtp-Source: APXvYqwPsqTcqJS47eac5g3/615emoR3QhyRePsEAaltaHx1C0IAoLdW/HEXb+4vWOZaCv+QEBSeMf/vx2Nwj4XjlWw= X-Received: by 2002:ac5:cdcd:: with SMTP id u13mr19180640vkn.0.1579123579845; Wed, 15 Jan 2020 13:26:19 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian Dickson Date: Wed, 15 Jan 2020 13:26:08 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Rob Sayre , Andrew Campling , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000087ff6059c345c84" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 21:26:26 -0000 --000000000000087ff6059c345c84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 1:01 PM STARK, BARBARA H wrote: > > > On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling < > andrew.campling@419.consulting> wrote: > > On Wed, Jan 15, 2020 at 19:24 Rob Sayre wrote: > > > Right now, my DNS server is 192.168.86.1, and encrypted DNS seems > designed to bypass it. > > > > Well, a lot of networking products (both consumer and corporate) have an > unencrypted DNS server on a private IP. > > > > I was wondering how the certificates would be constructed if they wished > to offer DoH or DoT. I know public services are able to get certificates > with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert fo= r > 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wonderi= ng > how private networks will offer encrypted DNS, and whether the debate > around the security considerations is important. > > > > thanks, > > Rob > > > > [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6 > > > > > Discussions I=E2=80=99ve had with people so far have been along the= lines of > (1) we=E2=80=99re not aware of any user-friendly/easy way to get a certif= icate into > consumer routers that will be ok=E2=80=99ed by a CA in browsers=E2=80=99 = trust stores, (2) > the user experience of doing https to a consumer router from a browser is > pretty horrible and scary, (3) some of these routers (e.g., Netgear) don= =E2=80=99t > even allow users to change what the router sends in DHCP/RA (it=E2=80=99s= always > the router=E2=80=99s private IP address; but the user can change what rec= ursive > resolver the router then uses), and (4) many people are unconvinced that > the threat of compromise inside the home network is worth the effort and > negative user experience. > > The other relevant question for those consumer boxes is whether they are full resolvers, or if they are merely forwarders to an upstream resolver that they learn from e.g. DHCP or RA. (Some even advertise their own IP, but only do NAT without any real DNS functionality, and literally forwarder the packet, rather than the query, from what I understand.) If the upstream resolver can be identified and is reachable directly, that potentially makes the middle box a moot point, as the client would have the ability to do whatever the WG adopts, to the real upstream resolver. Making that sufficiently user-friendly on the client side, and scalable and operable on the resolver side, are pertinent questions. I expect the user experience would be better, and the security model much better, when bypassing the middle box. The threat potential would still exist outside of the home network if a forwarder was used without using an upgraded transport, between the middle box and the upstream resolver. This threat would be addressed indirectly if/when the middle box were bypassed entirely. This model presumes the upstream resolver is the resolver discovered, and would not change the actual (functional) resolver being used. Brian --000000000000087ff6059c345c84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 15, 2020 at 1:01 PM STARK= , BARBARA H <bs7652@att.com> wr= ote:

=C2=A0

On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling <= ;andrew= .campling@419.consulting> wrote:

On Wed, Jan 15, 2020 at 19:24 Rob Sayre <= sayrer@gmail.com> wrote:

> Right now, my DNS server i= s 192.168.86.1, and encrypted DNS seems designed to bypass it.

=C2=A0

Well, a lot of networking products (both consumer an= d corporate) have an unencrypted DNS server on a private IP.<= /p>

=C2=A0

I was wondering how the certificates would be constr= ucted if they wished to offer DoH or DoT. I know public services are able t= o get certificates with SAN[1] extensions containing public IPs (e.g. the C= loudflare cert for 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering how p= rivate networks will offer encrypted DNS, and whether the debate around the= security considerations is important.

=C2=A0

thanks,

Rob

=C2=A0

=C2=A0

<bhs> Discussions I=E2=80=99ve had with people= so far have been along the lines of (1) we=E2=80=99re not aware of any use= r-friendly/easy way to get a certificate into consumer routers that will be= ok=E2=80=99ed by a CA in browsers=E2=80=99 trust stores, (2) the user expe= rience of doing https to a consumer router from a browser is pretty horrible and = scary, (3) some of these routers (e.g., Netgear) don=E2=80=99t even allow u= sers to change what the router sends in DHCP/RA (it=E2=80=99s always the ro= uter=E2=80=99s private IP address; but the user can change what recursive resolver the router then uses), and (4) many people are unc= onvinced that the threat of compromise inside the home network is worth the= effort and negative user experience.</bhs>



The other relevant question for those = consumer boxes is whether they are full resolvers, or if they are merely fo= rwarders to an upstream resolver that they learn from e.g. DHCP or RA. (Som= e even advertise their own IP, but only do NAT without any real DNS functio= nality, and literally forwarder the packet, rather than the query, from wha= t I understand.)

If the upstream resolver can be i= dentified and is reachable directly, that potentially makes the middle box = a moot point, as the client would have the ability to do whatever the WG ad= opts, to the real upstream resolver.

Making that s= ufficiently user-friendly on the client side, and scalable and operable on = the resolver side, are pertinent questions. I expect the user experience wo= uld be better, and the security model much better, when bypassing the middl= e box.

The threat potential would still exist outs= ide of the home network if a forwarder was used without using an upgraded t= ransport, between the middle box and the upstream resolver. This threat wou= ld be addressed indirectly if/when the middle box were bypassed entirely.

This model presumes the upstream resolver is the re= solver discovered, and would not change the actual (functional) resolver be= ing used.

Brian
--000000000000087ff6059c345c84-- From nobody Wed Jan 15 13:30:35 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CC5120992 for ; Wed, 15 Jan 2020 13:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 BuFvT5kpkupx for ; Wed, 15 Jan 2020 13:30:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D98120984 for ; Wed, 15 Jan 2020 13:30:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 852F3BE20; Wed, 15 Jan 2020 21:30:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trHJjSKrFXhH; Wed, 15 Jan 2020 21:30:23 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 05E33BDCF; Wed, 15 Jan 2020 21:30:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579123823; bh=NrQq8V9YluxFl1JBAbhw1FPinLme6hGlleR38hZ8x9c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hBVK0oOEiYtEvfMEcDHsu+icdMnI+G3sZ0DOEceqfaZYLgC8AegNuHrYKPUDKKib6 71LDPgbGgPxb8uv6eJzzNwB9Dtm+3RK4UWE3Zhddt3+h33m8d9GCo0iWd3CAMrWn2R 7jK+KAuPRzsROaOX/iyIjtuvH2N+PJn1zVAVPXGA= To: Ted Lemon , Barry Leiba Cc: ADD Mailing list , Dave Lawrence References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> <7368AE4B-1BA2-4BFE-97AE-D0523D3B72A5@fugue.com> From: Stephen Farrell 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: <2327c897-c92d-4c06-198e-2beed2ac7de5@cs.tcd.ie> Date: Wed, 15 Jan 2020 21:30:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <7368AE4B-1BA2-4BFE-97AE-D0523D3B72A5@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0PcomHtEzcZjAAQKgZMiHQwtzX0KwXIKj" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 21:30:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0PcomHtEzcZjAAQKgZMiHQwtzX0KwXIKj Content-Type: multipart/mixed; boundary="XD2rkMIrAU8lsSBnazYEkVCPtNqKhfV1s"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon , Barry Leiba Cc: ADD Mailing list , Dave Lawrence Message-ID: <2327c897-c92d-4c06-198e-2beed2ac7de5@cs.tcd.ie> Subject: Re: [Add] [Ext] Updated charter proposal for ADD References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> <7368AE4B-1BA2-4BFE-97AE-D0523D3B72A5@fugue.com> In-Reply-To: <7368AE4B-1BA2-4BFE-97AE-D0523D3B72A5@fugue.com> --XD2rkMIrAU8lsSBnazYEkVCPtNqKhfV1s Content-Type: multipart/mixed; boundary="------------36A502C6AB5175DAD877A8B7" Content-Language: en-US This is a multi-part message in MIME format. --------------36A502C6AB5175DAD877A8B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/01/2020 21:25, Ted Lemon wrote: > That said, I have not actually heard anybody other than you and Paul > object to the new language I proposed, FWIW, I don't your suggestion solves the problem. (Without arguing for any particular outcome) I'd like the WG to be able to consider opportunistic solutions as well as strongly authenticated ones. I read your text as strongly arguing that the former (oppo) not be included. To be clear - personally, I'd argue against a whole bunch of the opportunistic solutions I could envisage in this space, but maybe not all of 'em. Cheers, S. --------------36A502C6AB5175DAD877A8B7 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----- --------------36A502C6AB5175DAD877A8B7-- --XD2rkMIrAU8lsSBnazYEkVCPtNqKhfV1s-- --0PcomHtEzcZjAAQKgZMiHQwtzX0KwXIKj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4fhG0ACgkQWrL68XsX K+q7mA/8Cm4ZoT7aClTtV9/QcUoib+ZPa4JOOThZN07ZqlwjXjl1yAPiLzhlUy6d 4/ZMGSY6UIUGehfjTqh22RXvBnoS0bb2qw9lOx2zx+BWe7ysii0hG6W8WaYyrN+p faMowRH80jUKeW2dRt4GpvN+83M8jTP5vPuel7Bq9quNPfCgMf6MONZOuI6qcoQj H5YVXkGCIWH78BtB77eBRj23ntPbHsJoKlY77oVEn49ndKxobdPtG2ffr2Z7Vor7 UdwRCnXgq/iOsuM1VbNMum0kc/mfkB11/CrQwGpFvgfGjG41eIqtg/2GrW0O41Rg cmTv5gjwTXjIqrhd9g+klW9mjky8b5VbEcu1HyRrOUWBCUBmkTNDmflOIwgRTCF3 NjJXzAyWyJv1EP7TtYVDVyhoHkMdzsOmlBmTWk/FS7Uu8dd4FGE9vWMgAS0yKGe2 rWJAKWg+IXZCRQUtYsWBB2OWNod2rjulnFyTd+UCb+qmv2fymQJVnrykdx+HoXLh xaRU2A3uaqXbLFiO681pnDvlNoppWa7Sk3aXmsH7XNRlonr56IIyiy/bUWodXdom TKB23cOmlxqTHOkhspzfLklHfF+Ijqc+koSgbdqvj0BLKDM5aOSIAuZl9UOFxKAT wNmipUeCD5yrasUAwYVOkzTN6+ZuP+YAVJhagR/SBBN/Ujzmmkk= =EVD6 -----END PGP SIGNATURE----- --0PcomHtEzcZjAAQKgZMiHQwtzX0KwXIKj-- From nobody Wed Jan 15 13:32:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54331209C9 for ; Wed, 15 Jan 2020 13:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 X6JxjUiXGv-0 for ; Wed, 15 Jan 2020 13:32:28 -0800 (PST) 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 0C3B0120A0D for ; Wed, 15 Jan 2020 13:32:28 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id d5so17143937qto.0 for ; Wed, 15 Jan 2020 13:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IBbs8jGyHNI+vMC/cBS/ErtciwjrkUVS0RfOpY+uqUI=; b=1A6FX+i6XB931JWguoLNLh73DVySete3UMWWcQpuT8PlxYWajBti3RVyFxprc1A9eX 0IN6fSs1ABBr/8lB4EnWyaa+Nyjdqe1N/EI4BZup+DZF9KBbIEUSWu612X3clPKKoKBn X8dwwP83J4i2uNhOckHyclX4wEgV0nLyMZHorKRiC8PImN5OynHTqmP3JFOlP0tfUtE+ VM0EZJS1W7sc5rYALIC+wY9ZK2n6SQ3P8bEXzRJ5psEyH0DdApUVeB78irs0bhrcoHPf /7DxDEtFSbYYG6vDDgV9LgoA8hDrjGl/FO6vam9fyg5p+3EiuQztg0AYNg5/n7hoFpqb IxjQ== 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=IBbs8jGyHNI+vMC/cBS/ErtciwjrkUVS0RfOpY+uqUI=; b=SYoRN6vkVjGkwzQRUquKkx90c0jEBVmwOkACuurdD7rdVyQ0Hld1j8QRlw9wIEcG9q WH74ladIxPSUob9c0adyGcmclYvONZhyoeNWX6/4a40e4SQF8Nm6DaBkKtSdp7arO00U 0Ali8bJYRWPBfUFNWAbSXxIId9weF0g67LKeC0qS+TBlfWI9SeCOjjS4S2jLXBee1Q7t 8WQtAA65HMJahYZhD4vQsHP00tGVD8pMh0j2rc2Y9zBexoh/x4WYigPbRVt1XTy7CdbY 9kMZwXetW3xau169bAW1foYVj93++jzt0Z8ca4YtViMpRytOImXUmv3wfxx1+6NrLaXx ENuQ== X-Gm-Message-State: APjAAAVyqRRguKfb6qWOFynFZOsLx0hk9xeiR9/98NGMvJpc9b/I+jDC i4zUz4yv/4yL5jv9bTiMAauNcQ== X-Google-Smtp-Source: APXvYqzJw/TkbicUeOytO0qUxqfATWUooDDuemfp0AH2lBUv5AWXuuAwg2PgGZf5XL3OlKWRBYABKw== X-Received: by 2002:ac8:5059:: with SMTP id h25mr704688qtm.20.1579123947172; Wed, 15 Jan 2020 13:32:27 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id s20sm9046317qkg.131.2020.01.15.13.32.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 13:32:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) From: Ted Lemon In-Reply-To: Date: Wed, 15 Jan 2020 16:32:24 -0500 Cc: "STARK, BARBARA H" , Andrew Campling , ADD Mailing list , Rob Sayre Content-Transfer-Encoding: quoted-printable Message-Id: <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Brian Dickson X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 21:32:30 -0000 FWIW, for those who aren=E2=80=99t aware of this, the main point of = having a DNS Proxy on your home router (at 192.168.1.1, for example), = the reason is primarily timing. The ISP might change the IP address of = the DNS server (although it rarely does), but more importantly if there = is a power failure, and your home router becomes reachable before the = ISP connection comes up, and your host connects to it during that gap, = the router won=E2=80=99t have a DNS server IP address to offer your host = other than its own. For the case where we want the home router to support a secure DNS = resolver, the proxy could simply be a tunnel to the DNS resolver: before = the ISP connection comes up, names can=E2=80=99t be resolved, so = there=E2=80=99s no problem, and when it does come up, then the TLS = handshake will actually be with the ISP=E2=80=99s resolver, which will = have an identity, not with the home router. Even if the home router offers a value-added resolver service, the same = principle would likely apply. So before we go off and invent solution = to this problem, we should make sure we need a solution. From nobody Wed Jan 15 13:33:09 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F03E120984 for ; Wed, 15 Jan 2020 13:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_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 WIlds0l1GgBC for ; Wed, 15 Jan 2020 13:33:06 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 3C60112097F for ; Wed, 15 Jan 2020 13:33:06 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id z3so8120654qvn.0 for ; Wed, 15 Jan 2020 13:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6iCX1J1GtNTcPoyssi16SfXUMqTQmNSmbUkZ+z4ZaaI=; b=gWwRR+8mMHj+rHLEsvtJuPE14uyCFPhA9SKT0tej8ttnVdKxpbwF5b//WIgxfOUwFN gx2CMNEvghcNuR3yLHXj/DW66lhSNKYvcU79KiicE2Aothn+cHxCabZliuSqg6Pv6EAM pO505qnauWM+eZ64iKG+CHeik2V8RtzkjO1Vib8vkZGqY9dCvGklXyoWT5fLrlMiSjth /SMWlx4vp62QfoeGDphD1+I+9b/PeplyKKFW2DykIDeJAVwBBG6SK3CZ+us2GeU+weFz JkDIDpGBEA5VwZPoQABiF2MMPk3HARTz9wz4NWTkygq+9qVZd/89GcoUVxiTDkEmuAw7 IHBw== 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=6iCX1J1GtNTcPoyssi16SfXUMqTQmNSmbUkZ+z4ZaaI=; b=ciwsFhHa9tbrJySQEj6Exisyotvq+7mpVJjLPKLmdWZjuAA8rRSpRblr0jYjRsC5Sh DzPKZm8eEmY/5zbE67VkEaImgxAojgmxsRxMRfxJvGWgf1Oj0EOGLm0y0hE0LGc049Qp z6U3vyUOCRaaHkidYz0sv41nTBNeAvNccTpiywnHHn2nsyjI3BDvaLJQLfzVB4vtYKHu 2Uy+7bBUNDfMFltpI14IpTf2vo9JM2/GVnw4E1UUA9mHDtvkIDmK2ClRDZ8LB8MYpqEU j6fd1x7nIVeIFkeYZs0lIjtPcYq+9O/jojalOlSB7ae0VffxZfWkH1KlvtgL+XCy1mf4 cElg== X-Gm-Message-State: APjAAAU36mTGQomjfH2hEt2wuHoW80VPAU1AFR9Kb7/fq4xR8Svv1KN/ OFVM8krsmqvgb2f5wxFAUW5W1A== X-Google-Smtp-Source: APXvYqzFJqDH7HZ01UeNNv1qag0ywx1uGD1/ril5kIPA2ih1dkPTbEw126+jcKQfAyOHZXZuGLM9eA== X-Received: by 2002:ad4:4810:: with SMTP id g16mr27078088qvy.22.1579123985318; Wed, 15 Jan 2020 13:33:05 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id s20sm9046317qkg.131.2020.01.15.13.33.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 13:33:04 -0800 (PST) From: Ted Lemon Message-Id: <1BE4F65D-27EC-4ED7-82EF-61F9F105AFFC@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E5E76293-AF53-4ABB-BE14-CBAE6BA12D19" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 15 Jan 2020 16:33:03 -0500 In-Reply-To: <2327c897-c92d-4c06-198e-2beed2ac7de5@cs.tcd.ie> Cc: Barry Leiba , ADD Mailing list , Dave Lawrence To: Stephen Farrell References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <24095.13730.124469.943932@gro.dd.org> <87B74D88-8991-4F16-8AF6-8435BDB60AB1@fugue.com> <7368AE4B-1BA2-4BFE-97AE-D0523D3B72A5@fugue.com> <2327c897-c92d-4c06-198e-2beed2ac7de5@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 21:33:08 -0000 --Apple-Mail=_E5E76293-AF53-4ABB-BE14-CBAE6BA12D19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 4:30 PM, Stephen Farrell = wrote: > (Without arguing for any particular outcome) I'd like > the WG to be able to consider opportunistic solutions > as well as strongly authenticated ones. I read your > text as strongly arguing that the former (oppo) not > be included. OK, if that=E2=80=99s the case then the wording is wrong, because I very = much support the opportunistic solution. --Apple-Mail=_E5E76293-AF53-4ABB-BE14-CBAE6BA12D19 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 15, 2020, at 4:30 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
(Without arguing for any particular outcome) I'd = like
the WG to be = able to consider opportunistic solutions
as well as strongly authenticated ones. I read your
text as = strongly arguing that the former (oppo) not
be = included.

OK, if that=E2=80=99s the case then the wording is wrong, = because I very much support the opportunistic solution.

= --Apple-Mail=_E5E76293-AF53-4ABB-BE14-CBAE6BA12D19-- From nobody Wed Jan 15 14:20:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86212120992 for ; Wed, 15 Jan 2020 14:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 mDZqRcjCmzpB for ; Wed, 15 Jan 2020 14:20:38 -0800 (PST) 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 8FAD512010C for ; Wed, 15 Jan 2020 14:20:38 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id d15so19602253iog.3 for ; Wed, 15 Jan 2020 14:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2b9ixfekmB+03FwRVbUxwH8MrLqYH8J41XDNIPGktCQ=; b=mckDE5zMmOFz48qvJExzD0zvBV1kZk4akBGbEvpbxaQC5mdEJOi3aWteSHh2d+J2R6 wEpX5FuFGCiBK33kuh6pFlnxRtGTTpd16cNWeBb8i+iXQWXeU6NIVaB5/Slz49NsRkNa UnnBI/L168l2+HpGibaanbBlCP4XObx6nEwpO04xz9FcKeB8d4j7K/UNxzgE7s05frfJ 4i1V7i2QoIPnzIvenwVUAP8ZUkIAFJxiv1iwIGOsv9cpHgpTSxBsO8hTLsbIKKUfHePp m2Cl8S9PvBZq4cZ3XR7G8CY/lzzCSIm1PQordSPIk39KdX/OLdn0kJfIepBEptz4XJZV tDeA== 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=2b9ixfekmB+03FwRVbUxwH8MrLqYH8J41XDNIPGktCQ=; b=b2Tz6RUvNkGl6FEDMCgZNypOCgEPhEnaCQcxN1peumIGZSb7nGD/FMdoEGQiYhaNzP fWx51BxEqhYLC5PnrgedH4Bt0TeN4mtP4VB/j/LqxoueKeDeYOLra9zeJlIXgCRq3uVA nvabPJGQvpVIiU4xoL2q8X6ztF5ont/DC1SwRvoNrtVjDKsjviXfndf1E6Fs3gjyDehP abU1Gk3e8w55RpJqa/7rHKDzHjEgILMxEv40iknsgl3fwZh2ZxKWuqYp6xXqAGE6dB5d Mf+6aX8BGzEIbKeQRNpahfjXi8g3zD++qjDKdBJUtzc2Y2hjs6kmPnpREgb7BoKkhP+w CiFA== X-Gm-Message-State: APjAAAUiCn+yrcC0CjvS/3RAPDbj2rq2r0gTL31gbfbMcn6GtFKLoM3/ JLSyXU4Wdb5Vk1deNEUbTklXE9bp1XbY8R07ll8= X-Google-Smtp-Source: APXvYqzRsKiJW3psy44Y/d1wsRk24ynjTuOrqnbhLLw6+l2/eYdSyYwOeJgLWFl1FOBTdeRg7EDoD9uWalH1h7Brtng= X-Received: by 2002:a6b:731a:: with SMTP id e26mr23260894ioh.254.1579126837698; Wed, 15 Jan 2020 14:20:37 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> In-Reply-To: <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> From: Rob Sayre Date: Wed, 15 Jan 2020 14:20:25 -0800 Message-ID: To: Ted Lemon Cc: Brian Dickson , "STARK, BARBARA H" , Andrew Campling , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000377ab1059c351e26" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 22:20:40 -0000 --000000000000377ab1059c351e26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 1:32 PM Ted Lemon wrote: > FWIW, for those who aren=E2=80=99t aware of this, the main point of havin= g a DNS > Proxy on your home router (at 192.168.1.1, for example), the reason is > primarily timing. > The point wasn't limited to home routers, although it does apply there. thanks, Rob --000000000000377ab1059c351e26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 1:32 PM Ted Lemon= <mellon@fugue.com> wrote:
FWIW, for those who aren=E2=80=99t aware of this, the main point= of having a DNS Proxy on your home router (at 192.168.1.1, for example), t= he reason is primarily timing.=C2=A0

Th= e point wasn't limited to home routers, although it does apply there.

thanks,
Rob=C2=A0
--000000000000377ab1059c351e26-- From nobody Wed Jan 15 14:27:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077AC120992 for ; Wed, 15 Jan 2020 14:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 BUtwFZ5lo4zu for ; Wed, 15 Jan 2020 14:27:09 -0800 (PST) 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 1B7FC12010C for ; Wed, 15 Jan 2020 14:27:09 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id t129so17301415qke.10 for ; Wed, 15 Jan 2020 14:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eJPqoVMjLq8PQXMCh7x5gQ3uuM1bIGqU03bkplhGIQw=; b=pPL4Y6fBmueBicMJDIQ0l4d9p9RW7Q/1zoR3RIsh42//33LxmpmCCJRUnkvPeRgKXd eKQyPQDF6T6IE3oacbsMcHmd5Qo+ON5QkF2BuuVstgAlfzMY+0EkcYZ8efK3Yty7BHdm 3pQYGhfsuEHTdzlu3VyWtwOQalpImXkUcjmy2tTSAybY672T5jL8W0s7xeMfmGbPsYg1 6uL070hcNKoLb8IPvmRNLIK1UVcgQHH8WPVjTMcMA3be5vX6HroWtyj6uuqo1SAOmrGP 0djpleJcwRlpwen1tR8Bt8gpSpM6XafxxlVyjom7Jqw0P0asWEQAIsVqkyqixlj8Y4SC pe7w== 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=eJPqoVMjLq8PQXMCh7x5gQ3uuM1bIGqU03bkplhGIQw=; b=Vc2Cx5nccbaGye2iiwy4jIldvf89+UntT6TagmQj7dtlyt8wePDzD9RMYYv8sCVs/N 8S/0EfqQwCz8kzkQmq+YjCJgX3R089vCiJwZ2EygkIUoBvJjV4XsCKgeDwJKfK7j2LZ3 l75W1EBAmGAa7dPu9B43NZbFzWxWhgYRkj/u1TIhEUV0ecFVXn+hBJhfIxx0NA8jSQNo GB4gytsqMn1Te7SYnLaSAYmlIko5jxujvIUDqQh+KKg62KqH/xdP6TQuCQx6UNlEWY3S 8R33QOI85SXEE7OevZkMHiZdbCCVu0OXhh1UkdMIejQC01RQzUXpaHLmZhG2SgflSEnr AVqw== X-Gm-Message-State: APjAAAVGawwXCCFySf8Y7sefvoUf9pjIbd1R5fcC2HLALgpCiUGYEIYR iw8MPwNzb8D5cA9ZGTlYxjSU2w== X-Google-Smtp-Source: APXvYqyRJUejjscuUmpWZGFEbyfKAmFih/S7pGkrvmVuqBZx3O57LQKL+rrmP4Zkn+Z6v1ebvHEGJw== X-Received: by 2002:ae9:e707:: with SMTP id m7mr29184799qka.320.1579127228190; Wed, 15 Jan 2020 14:27:08 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id o10sm9946586qtp.38.2020.01.15.14.27.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 14:27:07 -0800 (PST) From: Ted Lemon Message-Id: <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BAF9E35B-D02C-4A30-BDE3-397E2A096EFD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 15 Jan 2020 17:27:05 -0500 In-Reply-To: Cc: Brian Dickson , "STARK, BARBARA H" , Andrew Campling , ADD Mailing list To: Rob Sayre References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 22:27:11 -0000 --Apple-Mail=_BAF9E35B-D02C-4A30-BDE3-397E2A096EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 5:20 PM, Rob Sayre wrote: > The point wasn't limited to home routers, although it does apply = there. OK. For an enterprise user, the easiest thing to do is just get a = cert. The IP address doesn=E2=80=99t matter. If you want to use = ACME, you might need to do some gymnastics, but you can make it work. = An operational document that describes how this works might be useful. = I don=E2=80=99t think there=E2=80=99s any new protocol work to do here. --Apple-Mail=_BAF9E35B-D02C-4A30-BDE3-397E2A096EFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 15, 2020, at 5:20 PM, Rob Sayre <sayrer@gmail.com> = wrote:
The = point wasn't limited to home routers, although it does apply = there.

OK.   For = an enterprise user, the easiest thing to do is just get a cert.   = The IP address doesn=E2=80=99t matter.   If you want to use ACME, = you might need to do some gymnastics, but you can make it work.   = An operational document that describes how this works might be useful. =   I don=E2=80=99t think there=E2=80=99s any new protocol work to do = here.


= --Apple-Mail=_BAF9E35B-D02C-4A30-BDE3-397E2A096EFD-- From nobody Wed Jan 15 14:49:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6247F120639 for ; Wed, 15 Jan 2020 14:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 acA5MPljuUw9 for ; Wed, 15 Jan 2020 14:49:13 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962D312010C for ; Wed, 15 Jan 2020 14:49:13 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id n21so19601668ioo.10 for ; Wed, 15 Jan 2020 14:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WU7CDIttbnAj0hfiNKuwplTB/dlZMJa2f8oxoxKwVXc=; b=r/GxApN1DdREYo/+P2lfnT7YHnpNtFjN0YSz6aIneYPnf0nfOXLSNrNKBPdHObfjUs POt/rmOvJ5Csluzg5oRxtG+eDbkTAJrZfV51zBxHiNomg+uHnQv+0DTfs7+4ArLxIKot QWEIEHbYrZpM4icZ+LEUaWsMq9led65ww/qFK8L4rBPgZpLyi8XFYd6BOAS150/BKifg xXdenfon3DFekxhGr1IqFADoRn/9KdawZu/JX/erkYR8nhWQlpTiNF0M3jEBBfj/vRWo mnA/it8yMFe5ziHsYL7/6djLmQuvVyfghSGPmU/BwBLCDwcBBiG/7c/Zi523HeC7FU8l ZP8g== 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=WU7CDIttbnAj0hfiNKuwplTB/dlZMJa2f8oxoxKwVXc=; b=LHb+VHnI59sz2tp248PgstIxAouQh0j9MGiHszA4U0b6G5rtEw/FbBiYRUpO4g3daJ 71SwtbArrmqK8WDWJS7HJe8XNcZE+x4d7Cd0ySgTn2OGV7h/i02EPlfmrOhQ5xAjjnYu xo2K4mOJ7IwXs+O8wttpFqjmfHiTk3TpmMta7s1Eu1hMtzLHuC1F4q1Tru/ikCE8Ab0b PaDswWwslThsH6iOjWiFjVFmpiVM2xQmWyjdZAfwFVMif6eFvAN9Rc+7bb/ufyBWhqRL +ZvWXofMjwgG84vP38cFytyGlUiY9Kd0k6XVdHm+flQYnZ+gPaHVJbUzpFsE7o8nfk8K 8mdw== X-Gm-Message-State: APjAAAVPAkgr8Tun9VLjRozqzeNeEq3V/vIMCssX035J4zbUMJOA9HWM rAaYmWiAgecNovtEGpQznQIAN6VvsnNUy0Epws4HN5UHCFNbfw== X-Google-Smtp-Source: APXvYqyNEZiOoqedG7holzrNFjw937BwJ7zXh7Nl5klPLSHzTV1lvz4UyvPLCE9jyiGoRy/0xdhK+ZsHJmaVXWhjYH4= X-Received: by 2002:a6b:731a:: with SMTP id e26mr23343799ioh.254.1579128552731; Wed, 15 Jan 2020 14:49:12 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com> In-Reply-To: <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com> From: Rob Sayre Date: Wed, 15 Jan 2020 14:49:00 -0800 Message-ID: To: Ted Lemon Cc: Brian Dickson , "STARK, BARBARA H" , Andrew Campling , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000070b99c059c358450" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 22:49:15 -0000 --00000000000070b99c059c358450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon wrote: > On Jan 15, 2020, at 5:20 PM, Rob Sayre wrote: > > The point wasn't limited to home routers, although it does apply there. > > > OK. For an enterprise user, the easiest thing to do is just get a cert. > The IP address doesn=E2=80=99t matter. If you want to use ACME, you m= ight need > to do some gymnastics, but you can make it work. An operational documen= t > that describes how this works might be useful. I don=E2=80=99t think th= ere=E2=80=99s any > new protocol work to do here. > I agree. When I read the charter, I'm wondering what's not possible today that these deliverables would enable, and why split DNS would be in scope, rather than an item for CAPPORT ( https://datatracker.ietf.org/wg/capport/about/ for those who aren't familiar). thanks, Rob --00000000000070b99c059c358450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon= <mellon@fugue.com> wrote:
On Jan 15, 2020, at 5:= 20 PM, Rob Sayre <= sayrer@gmail.com> wrote:
The point wasn't limited to home routers, although it does= apply there.

OK. =C2=A0 For an ente= rprise user, the easiest thing to do is just get a cert. =C2=A0 The IP addr= ess doesn=E2=80=99t matter. =C2=A0 If you want to use ACME, you might need = to do some gymnastics, but you can make it work. =C2=A0 An operational docu= ment that describes how this works might be useful. =C2=A0 I don=E2=80=99t = think there=E2=80=99s any new protocol work to do here.

I agree. When I read the charter, I'm wonderin= g what's not possible today that these deliverables would enable, and w= hy split DNS would be in scope, rather than an item for CAPPORT (https://datatracker.ietf.o= rg/wg/capport/about/ for those who aren't familiar).=C2=A0

thanks,
Rob

--00000000000070b99c059c358450-- From nobody Wed Jan 15 14:52:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A586120639 for ; Wed, 15 Jan 2020 14:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=foWTvlmg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xYiT16nM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx-KjDKVpMMC for ; Wed, 15 Jan 2020 14:52:51 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553AF12010C for ; Wed, 15 Jan 2020 14:52:51 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1152C513 for ; Wed, 15 Jan 2020 17:52:50 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 15 Jan 2020 17:52:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=QIUSHKhzRtV5RYMyYfpUmyPf350vvq/ rE0oCwAByVq0=; b=foWTvlmgb6qC3ZvgYwiMoZY629KtzmD4uKE3bjyQByPzwV5 hw04tIeo62y7kgx3bSzERP1U0C23Q5APhcvoh1vEvx/ectNItSIqkZIw8HBheFPC aU/m8iqNjY17HuM/ct8O257tDUoCQpyzHU7PaL6dKeB03w1aRpvmReV/pEa0vOQH l/GbDglIifAxckOxBwHHJKhDkJMNPwK1ZCjcaVIsF0vLTv6nwSSCeNuHNy4IedSc +24hAsDyLlCbfVbYtUqzKCrzOp6o1R65YlrEXKDH5XTwR2jNA4IkVGBVTY2Phc6f qV2arjUa148F+Sh2CnzxGtFsVMVJrqLRgOG03AQ== 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=QIUSHK hzRtV5RYMyYfpUmyPf350vvq/rE0oCwAByVq0=; b=xYiT16nMJKpAPV2vpMCG+E atbEWcOscORYeLyzfNwZqSnvH43UC8g+7L2gCwUJUfD77Ji9uBPJn28f23cK0aF9 vFjQSumGuz03QlDm/0jQ1Uk7uzJQxNlPzedfPZRM38a1R7AoDfrwBf0QW+z0cq+K 4nBRZPabo0LutmxoE5J2sHNAYaiIUYXJwaZZvKbtrmQGXmM3dUUT6tcfCSMaOASr kFLRtqSwLX+cxv/JiS+dLFwH1xxI41UXaYrZfOdhbSECBofJLNOig/uZd0OuqUen lBcjeHTup7tM/LQ4OgHF4lVDqLcUXICJu4ZL8X7gS/EjZcrHhYQd7hJskcCDdZtA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeggddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7925DE00A5; Wed, 15 Jan 2020 17:52:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: <24b8e2da-cfbd-4c77-aeaa-6c57b0f29162@www.fastmail.com> In-Reply-To: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Date: Thu, 16 Jan 2020 09:52:29 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 22:52:52 -0000 On Thu, Jan 16, 2020, at 02:13, Paul Hoffman wrote: > The following paragraph in the proposed charter is impossible to meet > for the vast majority of use cases that have been discussed on this > list: > > Any mechanisms that specify interactions between clients and > servers must provide the security properties expected of IETF > protocols, e.g., confidentiality protection, integrity protection, > and authentication with strong work factor. Would it be better if the charter said that the work products must include mechanisms that provide or allow for , but that mechanisms might only provide opportunistic security [cite RFC]. From nobody Wed Jan 15 15:00:18 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA24C120110 for ; Wed, 15 Jan 2020 15:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_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 GyCuIlH4N_S5 for ; Wed, 15 Jan 2020 15:00:10 -0800 (PST) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 0BC5D120113 for ; Wed, 15 Jan 2020 15:00:10 -0800 (PST) Received: by mail-qv1-xf29.google.com with SMTP id y8so8210157qvk.6 for ; Wed, 15 Jan 2020 15:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tw13xR/KMAJuzhDuCQzOsW02UlPt+UqviS1TqGwxbyQ=; b=zK6x7S6Viz7UxBil6D8t1Ya6Gq8eQk6/bQCdqwt4cuCg+qa1ISSwlJltulyptZg8VV I4mR2qEcUKpXgn4W0zLdp+ej2LfLTIqWffsajDctWvFhnzN8Li0hkDUp2CFZBvVN9XOV nqZHrZR5njJDY0dpl5UpMkWaa9tPcPWiFy4ssD5cFipoGa4zcbjCZwwfhj+1MyFZtcRX xcx+uMpL5kMr71YYA+N8DzZvYWcVTOOi5wOIzS+TW4mjeNJIygWq6RaK69KaQtoMsTOB M/aGnSj81qsIXsDW5+6aX1k7oi+APaKQglTpVq37Bph6be1oUugp/GJkd/ckLYwVALst HmhQ== 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=tw13xR/KMAJuzhDuCQzOsW02UlPt+UqviS1TqGwxbyQ=; b=Yk2fNET/WINvNIg1vpNic7PZhOZil/VH5cBxxMgbYhx/U7/kVKOUYbG7AHCM6kdLif sraI9KQCPqAWjer9g1zlBxoH6GdTKiVjY2tx6mBCNsYk6VJwaVMmYGH7UyeAE4Y3ugJA A9uGmLobzxOdhUv5l2RCi9bNvDGtLnsAzEYq1Iv9nKugQlDIb8I52ead03FQF2Cc6n9/ WGXTBU8kZMDeEo/dwUeNG78Z5jznR7B4KshVUfIykqHGMiYe+JcfWbgB9DfA21Wj7c2j WkL5TGSa6vmEELuGeCoYPTW0pmEn5xn1k8RL0M35aUGMRrMqiCRXFMSdu9z8t/AjrGme RJQA== X-Gm-Message-State: APjAAAUOiwB0gIR/7eSO0REWWyV8+76Gx606FKfhUS+P34ZIB1sCwRHE Zbn9Tzwb8J7HoO2qsIxYI99vbQ== X-Google-Smtp-Source: APXvYqy3T/19OilNWRh91xDcEN6Ca9mbIztCB6pXgKDLxmlNUc/NZugSNWlqKlaDdRx4Nw7YIbCbTg== X-Received: by 2002:a0c:b920:: with SMTP id u32mr23828064qvf.173.1579129209162; Wed, 15 Jan 2020 15:00:09 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id e3sm10095191qtj.30.2020.01.15.15.00.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jan 2020 15:00:08 -0800 (PST) From: Ted Lemon Message-Id: <82297173-9037-47BD-B861-EC38886338D8@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A27B264-3A6A-4E79-B823-32B653D344A0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 15 Jan 2020 18:00:07 -0500 In-Reply-To: Cc: Brian Dickson , "STARK, BARBARA H" , Andrew Campling , ADD Mailing list To: Rob Sayre References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 23:00:16 -0000 --Apple-Mail=_2A27B264-3A6A-4E79-B823-32B653D344A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 15, 2020, at 5:49 PM, Rob Sayre wrote: > I agree. When I read the charter, I'm wondering what's not possible = today that these deliverables would enable, and why split DNS would be = in scope, rather than an item for CAPPORT = (https://datatracker.ietf.org/wg/capport/about/ = for those who aren't = familiar).=20 I think split DNS is pretty clearly in scope=E2=80=94it=E2=80=99s a very = different problem than CAPPORT. If the language I suggested seems to = you to suggest that split DNS is not in scope, I didn=E2=80=99t word it = well (which sounds likely given Stephen=E2=80=99s reaction to it). --Apple-Mail=_2A27B264-3A6A-4E79-B823-32B653D344A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 15, 2020, at 5:49 PM, Rob Sayre <sayrer@gmail.com> = wrote:
I agree. When I read the = charter, I'm wondering what's not possible today that these deliverables = would enable, and why split DNS would be in scope, rather than an item = for CAPPORT (https://datatracker.ietf.org/wg/capport/about/ for those who aren't = familiar). 

I think split DNS is pretty clearly in scope=E2=80=94it=E2=80=99= s a very different problem than CAPPORT.   If the language I = suggested seems to you to suggest that split DNS is not in scope, I = didn=E2=80=99t word it well (which sounds likely given Stephen=E2=80=99s = reaction to it).

= --Apple-Mail=_2A27B264-3A6A-4E79-B823-32B653D344A0-- From nobody Wed Jan 15 15:00:46 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF2120A38 for ; Wed, 15 Jan 2020 15:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gqu7APQJsvq3 for ; Wed, 15 Jan 2020 15:00:36 -0800 (PST) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430F4120AB0 for ; Wed, 15 Jan 2020 15:00:32 -0800 (PST) Received: from pps.filterd (m0048276.ppops.net [127.0.0.1]) by m0048276.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 00FMx3wH025777 for ; Wed, 15 Jan 2020 18:00:32 -0500 Received: from usushmgip002.mail.tfayd.com ([216.178.109.236]) by m0048276.ppops.net-00176a04. with ESMTP id 2xf861uja9-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 15 Jan 2020 18:00:31 -0500 Received: from unknown (HELO ashemwp00035.mail.tfayd.com) ([10.40.33.204]) by usushmgip002.mail.tfayd.com with ESMTP; 15 Jan 2020 15:00:30 -0800 Received: from ashemwp00005.mail.tfayd.com (100.126.24.29) by ashemwp00009.mail.tfayd.com (100.126.24.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 15 Jan 2020 18:00:29 -0500 Received: from ashemwp00001.mail.tfayd.com (100.126.24.25) by ashemwp00005.mail.tfayd.com (100.126.24.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 15 Jan 2020 18:00:28 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (10.40.78.204) by ashemwp00001.mail.tfayd.com (100.126.24.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32 via Frontend Transport; Wed, 15 Jan 2020 18:00:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LuDWCdtBxF9MesVqyeBJ3607k+npXKXvD/wtlQF0H2W3BxD5dnmjGIx//gudrnvSoif5qFLsz+lgmikqKhnwuhYrxkDNXxdmBQbYvCevGF+BqJDDI6Ba5Hkji/lORgECw+cMssMYT/BPIwMFDzd1cGMvUIUIfro7pzn/souPK/lhlrF5CLkdmnq75g5y4FZKJ7KzHMnL4QvX/Sn6ax1X6CXpWENkAJjMX09QPSYegLp8AntiY+PbXveovuvdVbwivrmT3EBLJMnG8sQbfdDRwvk51v8zbcjSc/rqNgVNrsDFTAYdMv0JuJRhBJE3y7YgHO7Ec7TFoXDAoaKvKiTC1w== 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=6RS5/rmF3GFqfZy4WhKGRPTLGeHNBVlt2Ki4teA2kus=; b=NYk6jU2l4qxxD4oIXe18z4D4EAY0+YI6bGA17RmoaxcTH4FtrNXPEvjIDuL9gAebCKDiQ9YNElqWhxNzKldUWcKtnZ0vcQEidb22xlAeYIu7YupFu1ChcMFrtLMi9LSNkGKZVIrnbsHO+udvUpo4b+ZdiCBDLvX5cvEVrJ1MeQaw8lH5frlhz6EuOpdU1zOAVALw9JA37zozn1eTIueBohX6SWiwvAlmbmrmLd8oMuy5+PmBfa4mfYmVWAUsyUevJoi1XA2MI43Wk3mSZcMRWd71kuCBNvRPnCaySaFSmmavKJDZoL70wF5NJ1qzrPckMR+T0PAEbFvLL+Njf8ffgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6RS5/rmF3GFqfZy4WhKGRPTLGeHNBVlt2Ki4teA2kus=; b=e1j9ovxr7b7G1e+BieKUV6kHrCkjCnIY26lKyWlBpoO3QIqocHN75KBolkja36Wlws7yQcPrBJ0QPEWxnd7gS35Nq9UCgrDrZEafoIJa3t4z+W67V8pO5p9sMiSioznsZ6dt/SmwIZ3AGcLNBISww1SYvBe4h3FTokHSa7H1AtI= Received: from DM6PR14MB3993.namprd14.prod.outlook.com (10.141.186.71) by DM6PR14MB2665.namprd14.prod.outlook.com (20.178.29.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 23:00:27 +0000 Received: from DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592]) by DM6PR14MB3993.namprd14.prod.outlook.com ([fe80::1c3a:8cf7:ed09:9592%5]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 23:00:27 +0000 From: "Deen, Glenn (NBCUniversal)" To: Rob Sayre CC: Ted Lemon , Andrew Campling , ADD Mailing list , "Brian Dickson" , "STARK, BARBARA H" Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy/eTp60i3DeFL0yV6n8OcEsSCQ== Date: Wed, 15 Jan 2020 23:00:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2607:fb90:a683:2379:10ff:a210:34f3:9f8b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49393ceb-93fa-4aae-b644-08d79a0eb622 x-ms-traffictypediagnostic: DM6PR14MB2665: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(366004)(376002)(39860400002)(346002)(136003)(189003)(199004)(81166006)(6486002)(8676002)(86362001)(478600001)(33656002)(6506007)(53546011)(5660300002)(71200400001)(6916009)(6512007)(316002)(66946007)(66446008)(8936002)(66476007)(186003)(54906003)(66556008)(64756008)(2906002)(2616005)(91956017)(4326008)(81156014)(76116006)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR14MB2665; H:DM6PR14MB3993.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nbcuni.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VXp9r6poX338JtcPLAwh2rR17s19y+MwgIBLo4rNnM7VheHcS5TgzHQ4rE6AvQSAelSj+7RfMCGSza6YWlXMB4Cmqysk7ofYgCp1UUCt5q8wWo7NXSI3+4nB0dOPevbabwcNaQrzhMCf+L/MjBpo6JcyeFhyFWGtTrBjmw0Qo4ADYpzFqQTjh/f35Qk90gz43PrpDzKZ7+qBdbrYeinPgfiPmPj2wXqJkkDo9xacC90BN3x3LQm9IS+HRxIDNXJVdNclbgtFimWDACTvdwwMAWltO3lAVEsg8NamNSnIbqzla+ktGg4asbhM/MM0Q+xZAoSVKXfja4YVZ+qpmNL1crpzQptB9ILdqu8fmWAcq48fKfYR0W7pX6RfkxX3kTH52uiur3h3XED5TRuPQoIQAlSOy9zI9IvNFk1Itjr7d68ENcOmROnIVT5Lh5cDl1nEzIWOsejUNS/Ln5XE9O42o4yDl/C/CfXjzVr1JyQ8PkYxBlQ24045PZKVSU/7b0+ldr3GeWNmQIa/lKx1yHvRog== Content-Type: multipart/alternative; boundary="_000_C70ECC7674314FC2B5550E1D8D82B449nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 49393ceb-93fa-4aae-b644-08d79a0eb622 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 23:00:27.1365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wxcCcDH5CEbG8MBC+s0a7cjaZUjpRG2SGf3PWU755FZ08Rr/0tho2XQTf8Cg4JNLQptT8dzBte67L/ikuqrzJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB2665 X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-OriginatorOrg: nbcuni.com X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-15_03:2020-01-15, 2020-01-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 spamscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001150172 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 23:00:45 -0000 --_000_C70ECC7674314FC2B5550E1D8D82B449nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIEphbiAxNSwgMjAyMCwgYXQgMjo0OSBQTSwgUm9iIFNheXJlIDxzYXlyZXJAZ21haWwu Y29tPiB3cm90ZToNCg0K77u/DQpPbiBXZWQsIEphbiAxNSwgMjAyMCBhdCAyOjI3IFBNIFRlZCBM ZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+IHdyb3RlOg0K T24gSmFuIDE1LCAyMDIwLCBhdCA1OjIwIFBNLCBSb2IgU2F5cmUgPHNheXJlckBnbWFpbC5jb208 bWFpbHRvOnNheXJlckBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBwb2ludCB3YXNuJ3QgbGltaXRl ZCB0byBob21lIHJvdXRlcnMsIGFsdGhvdWdoIGl0IGRvZXMgYXBwbHkgdGhlcmUuDQoNCk9LLiAg IEZvciBhbiBlbnRlcnByaXNlIHVzZXIsIHRoZSBlYXNpZXN0IHRoaW5nIHRvIGRvIGlzIGp1c3Qg Z2V0IGEgY2VydC4gICBUaGUgSVAgYWRkcmVzcyBkb2VzbuKAmXQgbWF0dGVyLiAgIElmIHlvdSB3 YW50IHRvIHVzZSBBQ01FLCB5b3UgbWlnaHQgbmVlZCB0byBkbyBzb21lIGd5bW5hc3RpY3MsIGJ1 dCB5b3UgY2FuIG1ha2UgaXQgd29yay4gICBBbiBvcGVyYXRpb25hbCBkb2N1bWVudCB0aGF0IGRl c2NyaWJlcyBob3cgdGhpcyB3b3JrcyBtaWdodCBiZSB1c2VmdWwuICAgSSBkb27igJl0IHRoaW5r IHRoZXJl4oCZcyBhbnkgbmV3IHByb3RvY29sIHdvcmsgdG8gZG8gaGVyZS4NCg0KSSBhZ3JlZS4g V2hlbiBJIHJlYWQgdGhlIGNoYXJ0ZXIsIEknbSB3b25kZXJpbmcgd2hhdCdzIG5vdCBwb3NzaWJs ZSB0b2RheSB0aGF0IHRoZXNlIGRlbGl2ZXJhYmxlcyB3b3VsZCBlbmFibGUsIGFuZCB3aHkgc3Bs aXQgRE5TIHdvdWxkIGJlIGluIHNjb3BlLCByYXRoZXIgdGhhbiBhbiBpdGVtIGZvciBDQVBQT1JU IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2NhcHBvcnQvYWJvdXQvIGZvciB0aG9z ZSB3aG8gYXJlbid0IGZhbWlsaWFyKS4NCg0KSWRlYWxseSB0aGUgV0cgcHJvZHVjdCB3b3VsZCBi ZSBnZW5lcmFsIGVub3VnaCB0byB3b3JrIGZvciBhbnkgZG5zIGRpc2NvdmVyeSBhbmQgc2VsZWN0 aW9uIHNpdHVhdGlvbiBpbmNsdWRpbmcgc3BsaXQgZG5zLiAgIFNvIGtlZXBpbmcgaXQgaW4gc2Nv cGUgd291bGQgc2VlbSB1c2VmdWwuICAgQ2VydGFpbmx5IHRoaXMgZ3JvdXAgd2lsbCB0YWxrIHRv IGNhcHBvcnQuDQoNCkdsZW5uDQoNCg== --_000_C70ECC7674314FC2B5550E1D8D82B449nbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPk9uIEphbiAxNSwgMjAyMCwgYXQgMjo0OSBQTSwgUm9iIFNheXJlICZs dDtzYXlyZXJAZ21haWwuY29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+77u/DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPk9uIFdlZCwgSmFuIDE1LCAyMDIwIGF0IDI6Mjcg UE0gVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbSI+bWVsbG9u QGZ1Z3VlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsi Pk9uIEphbiAxNSwgMjAyMCwgYXQgNToyMCBQTSwgUm9iIFNheXJlICZsdDs8YSBocmVmPSJtYWls dG86c2F5cmVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNheXJlckBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZToNCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjE0cHg7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXIt c3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFu c2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDt0ZXh0LWRlY29y YXRpb246bm9uZSI+DQpUaGUgcG9pbnQgd2Fzbid0IGxpbWl0ZWQgdG8gaG9tZSByb3V0ZXJzLCBh bHRob3VnaCBpdCBkb2VzIGFwcGx5IHRoZXJlLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YnI+DQo8L2Rpdj4NCjxkaXY+T0suICZuYnNwOyBGb3IgYW4gZW50ZXJwcmlzZSB1c2VyLCB0 aGUgZWFzaWVzdCB0aGluZyB0byBkbyBpcyBqdXN0IGdldCBhIGNlcnQuICZuYnNwOyBUaGUgSVAg YWRkcmVzcyBkb2VzbuKAmXQgbWF0dGVyLiAmbmJzcDsgSWYgeW91IHdhbnQgdG8gdXNlIEFDTUUs IHlvdSBtaWdodCBuZWVkIHRvIGRvIHNvbWUgZ3ltbmFzdGljcywgYnV0IHlvdSBjYW4gbWFrZSBp dCB3b3JrLiAmbmJzcDsgQW4gb3BlcmF0aW9uYWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgaG93 IHRoaXMgd29ya3MNCiBtaWdodCBiZSB1c2VmdWwuICZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgdGhl cmXigJlzIGFueSBuZXcgcHJvdG9jb2wgd29yayB0byBkbyBoZXJlLjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFncmVlLiBXaGVuIEkgcmVh ZCB0aGUgY2hhcnRlciwgSSdtIHdvbmRlcmluZyB3aGF0J3Mgbm90IHBvc3NpYmxlIHRvZGF5IHRo YXQgdGhlc2UgZGVsaXZlcmFibGVzIHdvdWxkIGVuYWJsZSwgYW5kIHdoeSBzcGxpdCBETlMgd291 bGQgYmUgaW4gc2NvcGUsIHJhdGhlciB0aGFuIGFuIGl0ZW0gZm9yIENBUFBPUlQgKDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvY2FwcG9ydC9hYm91dC8iPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvY2FwcG9ydC9hYm91dC88L2E+DQogZm9yIHRob3NlIHdo byBhcmVuJ3QgZmFtaWxpYXIpLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWRlYWxseSB0aGUgV0cgcHJv ZHVjdCB3b3VsZCBiZSBnZW5lcmFsIGVub3VnaCB0byB3b3JrIGZvciBhbnkgZG5zIGRpc2NvdmVy eSBhbmQgc2VsZWN0aW9uIHNpdHVhdGlvbiBpbmNsdWRpbmcgc3BsaXQgZG5zLiAmbmJzcDsgU28g a2VlcGluZyBpdCBpbiBzY29wZSB3b3VsZCBzZWVtIHVzZWZ1bC4gJm5ic3A7IENlcnRhaW5seSB0 aGlzIGdyb3VwIHdpbGwgdGFsayB0byBjYXBwb3J0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+R2xlbm4mbmJzcDs8L2Rpdj4NCjxicj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C70ECC7674314FC2B5550E1D8D82B449nbcunicom_-- From nobody Wed Jan 15 15:13:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CD9120113 for ; Wed, 15 Jan 2020 15:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 u_sXTivA1ea4 for ; Wed, 15 Jan 2020 15:13:30 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 3710D120044 for ; Wed, 15 Jan 2020 15:13:30 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id g15so11544350vsf.1 for ; Wed, 15 Jan 2020 15:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PR2h+AbLgVAwvIFXeUd6EPdH1TAX5LB0/kGAR9zkELQ=; b=juOYV9Yu6beP4hf970CoiQ7nzWuCGa278POrniH1cKTjCmW3lpKnVjKiOGockBcmeG RtmOERIhwf5CzWDDir+I1rnyiJYI2n9HpnppMNoZnJZLwPzwbWPzSAifl8cXqwnW9QQI 6VJw6rsPiV5kd4rOwXRPx+n8EbO4mSnW1TgV5AcMoDFNReBc4CZS67YQbVy6NlS7Rp4e 3FanR4TA7th+cdF6TcVCSFqSyZwUNkDwDyT5VQBJf5iru8KLUJq5fnquhAh1nQhb4PtQ GQFEPL6Vi0Ot79HcqKWdIlrI6dBnBdgEIAuFLn7efTDLxpx3aHQ1tb9/4uw0Hw68qlO5 EtFw== 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=PR2h+AbLgVAwvIFXeUd6EPdH1TAX5LB0/kGAR9zkELQ=; b=DH5Qwq4NN8qwd2VKlZFmZR6m3M4lz6mdh5gs6ooELLFoUpordc0fi5HdX77LrUPONQ IuaH7K5NlQcqVOZJ95qbAwYbuP5pim67KxulbxRhsxFHwrEm7mrXLdX5gaZKbK3Xps4u FG0UYEIfCmD+GVnMQUG43wqpyMI1Bnaji0pnxtDa6ErdMy/VAHEzxwaZaKO/wuIKo1yI SvBpfDiDDCzA8G5MCmP79dXed6L8ovHMmG+RdNphHgpXHQ5uRCsZJyMdNSoqMjqbmWwU M/4tn1QqUb/3hFQvY+MkOK1g4XcIxVPl+sMzcZwpdYUNDdL7kH1BM/HDxoTG1E3cs4va crHQ== X-Gm-Message-State: APjAAAVkGLImJ/rB8Ex6JK00VzCegsCDqeSQ6gsc25WysVRwfru5TPuX 7xM9/IHqAdLIXYL++4DNFirW50F+txFIyWPwfEzb7ten X-Google-Smtp-Source: APXvYqxi2b42a1vveU2CvHwAueNiPZmNFT4YYcl1ZV3xoHqGlpx/65NiDEkZ4VYxPvch6yTymEnokYGDdHK+001PcCY= X-Received: by 2002:a67:f995:: with SMTP id b21mr6007433vsq.199.1579130009284; Wed, 15 Jan 2020 15:13:29 -0800 (PST) MIME-Version: 1.0 References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <66C24EE6-5C7B-4788-AE26-06B900915010@fugue.com> <2D09D61DDFA73D4C884805CC7865E611537457D1@GAALPA1MSGUSRBF.ITServices.sbc.com> <838B873D-CF56-4EE1-A331-5F17CE51C4F5@fugue.com> <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com> In-Reply-To: <8BD03712-645C-445E-9535-B22BB44A696A@fugue.com> From: Brian Dickson Date: Wed, 15 Jan 2020 15:13:17 -0800 Message-ID: To: Ted Lemon Cc: Rob Sayre , "STARK, BARBARA H" , Andrew Campling , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000041f389059c35dbd2" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 23:13:32 -0000 --00000000000041f389059c35dbd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon wrote: > On Jan 15, 2020, at 5:20 PM, Rob Sayre wrote: > > The point wasn't limited to home routers, although it does apply there. > > > OK. For an enterprise user, the easiest thing to do is just get a cert. > The IP address doesn=E2=80=99t matter. If you want to use ACME, you m= ight need > to do some gymnastics, but you can make it work. An operational documen= t > that describes how this works might be useful. > > I don=E2=80=99t think there=E2=80=99s any new protocol work to do here. > Maybe, maybe not. Or maybe not new protocol work, but separating which RFCs are informative vs normative might be a big issue. Specifically, it has to do with scope, when considering the question of certificate validation. The scope of the WG charter is larger than WWW use of DNS. The related scope question is whether it is appropriate to rely exclusively on the WebPKI rules (including trusted CAs) for validation of X.509 certificates used for DNS. This has to do with MTI, and interoperability. It isn't going to be a successful outcome to the WG if the result only works for browser clients incorporating WebPKI elements (trusted CA set, and revocation via OCSP/CRL/CT exclusively), as opposed to use of DANE (single trusted public DNS trust anchor, and revocation by unpublishing DNSKEYs in DNS) and possible use of non-public DNS trust anchors. Brian --00000000000041f389059c35dbd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 15, 2020 at 2:27 PM Ted L= emon <mellon@fugue.com> wrote= :
On Jan 15, 2020, at 5:20 PM, Rob Sayre <sayrer@gmail.com> = wrote:
The point wa= sn't limited to home routers, although it does apply there.
=

OK. =C2=A0 For an enterprise user, the easiest = thing to do is just get a cert. =C2=A0 The IP address doesn=E2=80=99t matte= r. =C2=A0 If you want to use ACME, you might need to do some gymnastics, bu= t you can make it work. =C2=A0 An operational document that describes how t= his works might be useful. =C2=A0
=C2=A0
<= /div>
I don=E2=80=99t think there=E2=80=99s any new pr= otocol work to do here.

Maybe, = maybe not. Or maybe not new protocol work, but separating which RFCs are in= formative vs normative might be a big issue.

Speci= fically, it has to do with scope, when considering the question of certific= ate validation.

The scope of the WG charter is lar= ger than WWW use of DNS.

The related scope questio= n is whether it is appropriate to rely exclusively on the WebPKI rules (inc= luding trusted CAs) for validation of X.509 certificates used for DNS.

This has to do with MTI, and interoperability. It isn&= #39;t going to be a successful outcome to the WG if the result only works f= or browser clients incorporating WebPKI elements (trusted CA set, and revoc= ation via OCSP/CRL/CT exclusively), as opposed to use of DANE (single trust= ed public DNS trust anchor, and revocation by unpublishing DNSKEYs in DNS) = and possible use of non-public DNS trust anchors.

= Brian=C2=A0
--00000000000041f389059c35dbd2-- From nobody Wed Jan 15 15:33:22 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C90512008F for ; Wed, 15 Jan 2020 15:33:21 -0800 (PST) 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 SaXAzL51W7eO for ; Wed, 15 Jan 2020 15:33:19 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20EB3120044 for ; Wed, 15 Jan 2020 15:33:19 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id 21so17495088qky.4 for ; Wed, 15 Jan 2020 15:33:19 -0800 (PST) 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=Sc75jWdNzD1qCaBfOCvQyxisQbbgxmtfzu2nMqf1Jhk=; b=M5nkWr06toAgGRL2vlPWSYaqqKWFj9k3B5EQ+khnDuJJbWKchkUEBxO7cirLfP5w+0 LknxnV02Q5uPPyUBIvfTlZcM7S/x0ERLwPTHuPx14I7aYXeV6Nz1fqgIQiXsmXOHSHkW +wCJZxIqRWfdDisAw0cz/NhpoXfm4WYb49UOpIk1fSz0qaj2BKV3idgig2f0qRGQjeYs ztD0yIwzYWJsQIHULKrhTrDXmQ815q5CUIhtkmVXe6ftMvojB5YTTaVUKC7lw3Kex0uT 9MFGs7bvnzoNF/XBK82XejRlDZ2IAcLTMNehq5Sp9vOyTag1MNh2tK6NrMXcx9DuoXZl nF2Q== 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=Sc75jWdNzD1qCaBfOCvQyxisQbbgxmtfzu2nMqf1Jhk=; b=Kxqs8Yrqn33NSgxVVRJPHZKxptPqJpBb3mg9EKNBNqlWG9KygUSJj+MvQHAJKYJRWC RegPngK2A/VdXRoZXxrHT0vypXOuDaGTjVltO46MDMLN/D3cOMa6pOOln2TV/RdPhJFl osol3j2cB6aeWU9imJG8DYkVOG5SVwwjwoLhS2qQGzhHzXZtQefwYrPHfLgFlFhaANVP pfHEmTTKfGd19AA6YkCrvf0zWRkBljnQWjDTBt5WGu/JWocmkAZtqb3db7VJEtNA0y1i 1S6/JUPnZxVzBylgipFp17y1iFPfDQWclJIuNyO4qeYv5rYOH61DnM+N1eHIBpph/TSd OVzw== X-Gm-Message-State: APjAAAVzi9p8gYW0PYXjMgI+yKa0rXrAkX9E8/r4x+uPvBEPFl5wqGQn 9M+h+LQiVGXEuoRwxoHOAl9CBQ== X-Google-Smtp-Source: APXvYqxiqDVTCoxqbXrA1/vpxV/V3jghoBWSkWCHDB6eGW+k1UU8afHDklWGHGl401Aquoh4SD43HA== X-Received: by 2002:ae9:ee11:: with SMTP id i17mr30349362qkg.333.1579131198266; Wed, 15 Jan 2020 15:33:18 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:c07e:acd:1cfa:abc7? ([2601:18b:300:36ee:c07e:acd:1cfa:abc7]) by smtp.gmail.com with ESMTPSA id o7sm9108559qkd.119.2020.01.15.15.33.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jan 2020 15:33:17 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-CDB76DB4-CA01-4954-A551-1748AA8FDF16 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 15 Jan 2020 18:33:15 -0500 Message-Id: <84E7C4F0-8C4D-4F33-ABF8-63DF3553638A@fugue.com> References: Cc: Rob Sayre , "STARK, BARBARA H" , Andrew Campling , ADD Mailing list In-Reply-To: To: Brian Dickson X-Mailer: iPhone Mail (17E202) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 15 Jan 2020 23:33:21 -0000 --Apple-Mail-CDB76DB4-CA01-4954-A551-1748AA8FDF16 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think it makes sense to use web PKI to establish trust, no. B= ut to validate a certificate? Sure. DANE is another good option, also not u= seful for establishing trust.=20 > On Jan 15, 2020, at 18:13, Brian Dickson w= rote: >=20 > =EF=BB=BF >=20 >=20 >> On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon wrote: >>>> On Jan 15, 2020, at 5:20 PM, Rob Sayre wrote: >>>> The point wasn't limited to home routers, although it does apply there.= >>>=20 >>> OK. For an enterprise user, the easiest thing to do is just get a cert= . The IP address doesn=E2=80=99t matter. If you want to use ACME, you mi= ght need to do some gymnastics, but you can make it work. An operational d= ocument that describes how this works might be useful. =20 >> =20 >> I don=E2=80=99t think there=E2=80=99s any new protocol work to do here. >=20 > Maybe, maybe not. Or maybe not new protocol work, but separating which RFC= s are informative vs normative might be a big issue. >=20 > Specifically, it has to do with scope, when considering the question of ce= rtificate validation. >=20 > The scope of the WG charter is larger than WWW use of DNS. >=20 > The related scope question is whether it is appropriate to rely exclusivel= y on the WebPKI rules (including trusted CAs) for validation of X.509 certif= icates used for DNS. >=20 > This has to do with MTI, and interoperability. It isn't going to be a succ= essful outcome to the WG if the result only works for browser clients incorp= orating WebPKI elements (trusted CA set, and revocation via OCSP/CRL/CT excl= usively), as opposed to use of DANE (single trusted public DNS trust anchor,= and revocation by unpublishing DNSKEYs in DNS) and possible use of non-publ= ic DNS trust anchors. >=20 > Brian=20 --Apple-Mail-CDB76DB4-CA01-4954-A551-1748AA8FDF16 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don=E2=80=99t think it m= akes sense to use web PKI to establish trust, no. But to validate a certific= ate?  Sure. DANE is another good option, also not useful for establishi= ng trust. 

On Jan 1= 5, 2020, at 18:13, Brian Dickson <brian.peter.dickson@gmail.com> wrote= :

=EF=BB= =BF


On Wed, Jan 15, 2020 at 2:27 PM Ted L= emon <mellon@fugue.com> wrote:=
On Jan 15, 2020, at 5:20 PM, Rob Sayre <sayrer@gmail.com> wrote:<= div>
The point wasn't limite= d to home routers, although it does apply there.
OK.   For an enterprise user, the easiest thing to do is ju= st get a cert.   The IP address doesn=E2=80=99t matter.   If you w= ant to use ACME, you might need to do some gymnastics, but you can make it w= ork.   An operational document that describes how this works might be u= seful.  
 
<= div>I don=E2=80=99t think there=E2=80=99s any new protocol work to do here.<= /div>

Maybe, maybe not. Or maybe not n= ew protocol work, but separating which RFCs are informative vs normative mig= ht be a big issue.

Specifically, it has to do with s= cope, when considering the question of certificate validation.
The scope of the WG charter is larger than WWW use of DNS.
=

The related scope question is whether it is appropriate t= o rely exclusively on the WebPKI rules (including trusted CAs) for validatio= n of X.509 certificates used for DNS.

This has to d= o with MTI, and interoperability. It isn't going to be a successful outcome t= o the WG if the result only works for browser clients incorporating WebPKI e= lements (trusted CA set, and revocation via OCSP/CRL/CT exclusively), as opp= osed to use of DANE (single trusted public DNS trust anchor, and revocation b= y unpublishing DNSKEYs in DNS) and possible use of non-public DNS trust anch= ors.

Brian 
= --Apple-Mail-CDB76DB4-CA01-4954-A551-1748AA8FDF16-- From nobody Wed Jan 15 16:09:04 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102A1120807 for ; Wed, 15 Jan 2020 16:09:03 -0800 (PST) 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 CCmNO9ftX1DH for ; Wed, 15 Jan 2020 16:09:01 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 32709120639 for ; Wed, 15 Jan 2020 16:09:01 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id p8so16490141iln.12 for ; Wed, 15 Jan 2020 16:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zc+WuewClyrmglbP7tEK6yBuv1ZjzNeWzE41Ri2UJuA=; b=bfxj4yAFxei4eLfn57zlwdJa40XMa/YkaD8nC2o9etuhLVfM4WcTVsqvLd65Ghdm5T 8141d7vCn0pfGVVg07DgyhMGcN37mTb7v+tI8hMcmbuXaX7ESCsWI+HuyPjGyApRTbMt arC90na9fHYB8DhCTaK5dezXxkYTi4VVHDOzg1wHu/Gh5T27UJhg+J2mLg/LUnLm5W27 Yn9LCtAR0GjYWJnOjcg0PhavIkOj+ylm9gIDSmB9piSFfupNl3oA33O1g96Ribz+A8aB 6RoU3To4pWueaMp2kEbZWAl/2LCB1gJeVWBDU0Q71ga8w/2D0R77rELOr6BXc5UD9Bwp 4N7w== 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=Zc+WuewClyrmglbP7tEK6yBuv1ZjzNeWzE41Ri2UJuA=; b=Ybfz6P1bvR0yXtzKafL1iTZlpEAON8M3O5mHhwE+X6OZjcZBKe3Sa8xjzMTxm07NH9 xIT2WJSE/JQWxZo8ZZ/7gPAXrlMCMpfq/pgDWp5GkSruycew2dHGxwQCFqLS7Zk5y+/A zwiFXox6EvtUNj5DVdQjP70nX/nBBopSS5PEAFlX+YhI2a2+KLbY+zb5/C3nHUT5n3jV fBw2PsNaBupUvAMXMKL9i3/qzb1M2gjatdMf3uBsrd7m91lKCzjR92ge06UHausE8k0d lcxVCEEJFzwAhG14n+eQ+idWU8oZKmxeTAGKcqEKhGKFw7Vh/cgQipGb2LYjjR/zuZM+ 8xUQ== X-Gm-Message-State: APjAAAUoQA41xUHInJUx0Uyebpnm79ane4jqOPzW+ROiPjJ2nobChPe6 QBKql4Y4ZC7VsDUJSmUZFZl8f8DcE/945mzEn84= X-Google-Smtp-Source: APXvYqzeLsKw8WzjBaxbBsQycS8IYvU3yiKsgYMXZ027g6IUH6yrl5gRxGjEf9qIDZXUf6q1tEvMjcBtMdW5OpldfR0= X-Received: by 2002:a92:1553:: with SMTP id v80mr1140743ilk.49.1579133340449; Wed, 15 Jan 2020 16:09:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Wed, 15 Jan 2020 16:08:49 -0800 Message-ID: To: "Deen, Glenn (NBCUniversal)" Cc: Ted Lemon , Andrew Campling , ADD Mailing list , Brian Dickson , "STARK, BARBARA H" Content-Type: multipart/alternative; boundary="000000000000cf81b6059c36a151" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 16 Jan 2020 00:09:03 -0000 --000000000000cf81b6059c36a151 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 15, 2020 at 3:00 PM Deen, Glenn (NBCUniversal) < Glenn.Deen@nbcuni.com> wrote: > I agree. When I read the charter, I'm wondering what's not possible today > that these deliverables would enable, and why split DNS would be in scope, > rather than an item for CAPPORT ( > https://datatracker.ietf.org/wg/capport/about/ for those who aren't > familiar). > > > Ideally the WG product would be general enough to work for any dns > discovery and selection situation including split dns. > Would it be possible to outline the interoperability problems the WG aims to address, even if it's not in the charter itself? Opportunistic encryption wouldn't seem to require a discovery mechanism. thanks, Rob --000000000000cf81b6059c36a151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 3:00 PM Deen, Gle= nn (NBCUniversal) <Glenn.Deen@n= bcuni.com> wrote:
I agree. When I read the charter, I'm wondering what's not pos= sible today that these deliverables would enable, and why split DNS would b= e in scope, rather than an item for CAPPORT (https://datatracker.ietf.org= /wg/capport/about/ for those who aren't familiar).=C2=A0

Ideally the WG product would be general enough to work for any dns dis= covery and selection situation including split dns.=C2=A0=C2=A0
=

Would it be possible to outline the intero= perability problems the WG aims to address, even if it's not in the cha= rter itself? Opportunistic encryption wouldn't seem to require a discov= ery mechanism.

thanks,
Rob
--000000000000cf81b6059c36a151-- From nobody Thu Jan 16 04:40:25 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C153212002E for ; Thu, 16 Jan 2020 04:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pqT5dbQ1S1G for ; Thu, 16 Jan 2020 04:40:18 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AAD12002F for ; Thu, 16 Jan 2020 04:40:18 -0800 (PST) Received: from tpw09926dag07e.domain1.systemhost.net (10.9.202.34) by BWP09926078.bt.com (10.36.82.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 16 Jan 2020 12:40:06 +0000 Received: from tpw09926dag07f.domain1.systemhost.net (10.9.202.38) by tpw09926dag07e.domain1.systemhost.net (10.9.202.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 16 Jan 2020 12:40:15 +0000 Received: from tpw09926dag07f.domain1.systemhost.net ([fe80::39eb:b031:eb4f:b2c9]) by tpw09926dag07f.domain1.systemhost.net ([fe80::39eb:b031:eb4f:b2c9%12]) with mapi id 15.00.1395.000; Thu, 16 Jan 2020 12:40:15 +0000 From: To: Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVyytcRtHa+WPLBEiaNmcxCCaIX6ftPU7Q Date: Thu, 16 Jan 2020 12:40:15 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.9.202.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 16 Jan 2020 12:40:24 -0000 Agree +1 -----Original Message----- From: Add [mailto:add-bounces@ietf.org] On Behalf Of Tommy Pauly Sent: 14 January 2020 22:38 To: ADD Mailing list Subject: [Add] Updated charter proposal for ADD Hi all, I wanted to share an updated proposal for an ADD charter, based on the feed= back and discussion on the list in the past several weeks. This is based on the original proposal that was sent in December, taking in= to account various comments and suggestions. Glenn Deen, Andrew Campling, a= nd I worked on this revision together and came to consensus on its contents= . Thoughts and comments are welcome as always! (Note that the proposed name of the group was not changed, and is entirely = open to bikeshedding. Naming is hard!) Best, Tommy Adaptive DNS Discovery (ADD) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Proposed Working Group Charter Sending DNS messages over encrypted transports, as defined in DNS over TLS = (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to = the security and privacy of DNS data. Clients, such as applications and hos= t operating systems, have started adopting these protocols to provide these= user benefits. This working group will focus on discovery and selection of DNS resolvers b= y DNS clients in a variety of networking environments, including public net= works, private networks, and VPNs; supporting both encrypted and unencrypte= d resolvers. Clients adopting encrypted DNS protocols need to determine which DNS server= s support encrypted transports, and which server to use for specific querie= s if multiple servers are available. These decisions can vary based on the = network environment, and also based on the content and purpose of the clien= t queries. Network operators that start offering DNS encryption on their servers also = need a way to indicate this support to clients. Communicating information a= bout resolver configuration and behavior allows clients to make more inform= ed decisions about which DNS servers to use. For example, a resolver may be= able to resolve private or local names as a split DNS server. The Adaptive DNS Discovery (ADD) working group will work on the following deliverables: - define a mechanism that allows clients to discover DNS resolvers, includi= ng encrypted DNS servers, that are available to the client either on the pu= blic Internet or on private or local networks; - define a mechanism that allows communication of DNS resolver information = to clients for use in selection decisions; - develop an informational document that describes how client applications = and systems can manage selection of DNS resolvers in various network enviro= nments and use cases. Any mechanisms that specify interactions between clients and servers must p= rovide the security properties expected of IETF protocols, e.g., confidenti= ality protection, integrity protection, and authentication with strong work= factor. This working group will coordinate with dnsop, doh, and dprive for any chan= ges required in DNS protocols. It will also work with capport to ensure tha= t solutions are applicable to captive networks. -- Add mailing list Add@ietf.org https://www.ietf.org/mailman/listinfo/add From nobody Thu Jan 16 04:43:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A9012004C for ; Thu, 16 Jan 2020 04:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 t_8-11m7iy38 for ; Thu, 16 Jan 2020 04:43:32 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.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 16032120052 for ; Thu, 16 Jan 2020 04:43:31 -0800 (PST) Received: from [46.226.52.203] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-west-1.aws.symcld.net id C8/66-23082-17A502E5; Thu, 16 Jan 2020 12:43:29 +0000 Authentication-Results: mx.messagelabs.com; dkim=none (message not signed); dmarc=fail (p=none sp=none adkim=r aspf=r) header.from=vodafone.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLsWRWlGSWpSXmKPExsWi75nTrVsQpRB nsHudgMX/0+vYLD6/XsBs8WnuAXaLh2cmsFj0THrF7MDqsenaTlaP650tzB4nll1h9Viy5CeT x5qGygDWKNbMvKT8igTWjGVPZrEWTOxlqmhrms/awHikk6mLkZNDSGA7o8TX+eFdjFxA9mFGi TfXVjBCOECJW/MeM0M4Fxklns1ewwbhTGSSWLxzKjuEc59RonfNHFaQYWwC9hKX1r0As0UEzj NK7DuqCGILCxhLbH8+jREibiLx+t9PdgjbSeLdnzlgh7AIqErs+HwcrIZXIEZi2vHJTBALDjF KXL3TzAyS4ARK3L39gw3EZhSQlfjSuBosziwgLnHryXywQRICAhJL9pxnhrBFJV4+/scKMohX 4CGLRMOELhaI5iiJnc862CCKFCXeHf7OCGHLSlya3w1l+0rs/TcRapCWxJeGy1ALsiWWnF4BF VeTuPGmA8jmALJlJJ5/jAfZJSGwlEXi5bSD0CBOkZi7cRs7RL2cxKrehywQtozEgxvb2SYwGs xC8gOEnSexqW0/+yxwYAhKnJz5hGUW0ApmAU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvor RIqkoMz2jJDcxM0fX0MBA19DQSNfQ0kzXyMBIL7FKN0kvtVS3PLW4RNdQL7G8WK+4Mjc5J0Uv L7VkEyMw9aUUHDm1g/HQ17d6hxglOZiURHlF9sjGCfEl5adUZiQWZ8QXleakFh9ilOHgUJLgb YxQiBMSLEpNT61Iy8wBpmGYtAQHj5IIrxUwFQvxFhck5hZnpkOkTjEGckx4OXcRM8fmX/OAZP vTBUDy3c/FQPLjqiVA8juYPDJ36SJmIZa8/LxUKXHelyB7BEAGZZTmwa2B5ZZLjLJSwryMDAw MQjwFqUW5mSWo8q8YxTkYlYR5RSKBpvBk5pXAXfMK6FAmoEMnOMuBHFqSiJCSamCSbJkX/Sz9 9cUPHFFzZPX0itXstrybcjj7r5K4rIes3I097RnrY3i6mm792se0NMugmsPPrYb7puya+U+7l 2yxEzm54c6y3usPmW+GJooHWYedzpgtNlHrr6eVj5vSJuGG7bPuCxscStMXNrtz+Gus+vrXnp PkXjdOKvl37w7vpnPc5odWcf61v3jor8jmGNk9M79NcVb5vy3W9M4Lh6TTjTcb2Q8U6TytXqs ho5i/5WPu5ecdF3cZsHmL6Ldrtulde/DnnoDu03A2jz+CIt1tMzaWXOE5duDTv1OqraV63pqf xIzSFcztdEUW2pjOZSj2Pv+1/Oedij9y29aUlbJmpTc0HftRHFf7Rdxzg7cSS3FGoqEWc1FxI gDnZWXRqAQAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-12.tower-291.messagelabs.com!1579178604!613165!14 X-Originating-IP: [47.73.108.139] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.44.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17644 invoked from network); 16 Jan 2020 12:43:28 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe01hw.internal.vodafone.com) (47.73.108.139) by server-12.tower-291.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 16 Jan 2020 12:43:28 -0000 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.46) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jan 2020 13:43:26 +0100 Received: from voxe02hw.internal.vodafone.com (195.232.244.47) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jan 2020 13:43:26 +0100 Received: from VOEXH09W.internal.vodafone.com (47.73.211.213) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jan 2020 13:43:25 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (172.17.213.45) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jan 2020 13:43:25 +0100 Received: from AM0PR05MB5730.eurprd05.prod.outlook.com (20.178.115.152) by AM0PR05MB4308.eurprd05.prod.outlook.com (52.134.124.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Thu, 16 Jan 2020 12:43:23 +0000 Received: from AM0PR05MB5730.eurprd05.prod.outlook.com ([fe80::8850:d3a3:a063:cfb7]) by AM0PR05MB5730.eurprd05.prod.outlook.com ([fe80::8850:d3a3:a063:cfb7%5]) with mapi id 15.20.2644.015; Thu, 16 Jan 2020 12:43:23 +0000 From: "Smith, Kevin, Vodafone Group" To: Andrew Campling , Paul Adair , Tommy Pauly , Glenn Deen , ADD Mailing list Thread-Topic: [Add] Updated charter proposal for ADD Thread-Index: AQHVyytkFcnOFtzCSEa0FUXLHiTY7qfrsxqAgAAsJYCAAVoooA== Date: Thu, 16 Jan 2020 12:43:23 +0000 Message-ID: References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> <0E6BAB56-3B54-4032-BD17-30770F242BB1@infoblox.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2020-01-16T12:43:21.4149250Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; Sensitivity=C2 General x-originating-ip: [47.73.248.223] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 251a3a79-c803-4d63-e9a0-08d79a81ac9a x-ms-traffictypediagnostic: AM0PR05MB4308: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(366004)(136003)(346002)(199004)(189003)(55016002)(76116006)(15650500001)(66446008)(64756008)(66476007)(66946007)(86362001)(8676002)(8936002)(81166006)(81156014)(5660300002)(66556008)(7696005)(110136005)(186003)(26005)(66574012)(52536014)(6506007)(53546011)(316002)(478600001)(9686003)(2906002)(71200400001)(966005)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR05MB4308; H:AM0PR05MB5730.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xjkZDlaXxzT/RZKsItwaw9P2Dn/o3OGkK2fjZ6iDbhEnvpnZsNbelSo2hIl/DFf+NFuQW4jMJn67mxoXAzLMdD7LMvvEVzBsHd24L2UK3BgGLVXiW41houcqA5TdA5AXspcKwl70BdMyLIRsIElXxIiXPNQ4i4H6lAxgM4fuaXa7u2RZM6H8AyJJOWMHGz/LS7DS/JeC7aqwerVFHNmSCFjRll6Cb0dTueQKblmdxxFqEd7T7n+ktYbgX03gZpd79BnxvZlIJAEQMXqo2pPznTctG04j4a72FhTEzMoLwYOLN/7LvVw4sWFtAuNvrp7WGks3k6WarMjiP99OlBPfwC5PTg3Lr5e54LmR2KnVbUtBine9Npw1l8rhlwc2j8V5XXtrb0jTGZcdqEPTepNKsCzHKCqYBk+11F5nAMCBj1haonI45qyXGfGaECt068Gg2Y5TkXK80y5hsh5TNAqApP2ggkJhMPd3Cz0aW8mL8Bg= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R2GC5fjzdS/hNw+pcv6lxKUM1596UB55cKJ69No/AMptnUfcb4DvWhtVqJZV1RtArAfQFWvdcSyqv4lucTb3eIhR+lelQh2gfA4MQr3bxrpxvtBUvdjEJwiOZfLcfvGrK8vBSCfSL+D4ajJa1cCh5a1UyjXJw8vGQZXn6SamJBpzhkPRVmN4lZ7EE4u01a9bKJzmlqxBq9vasJSVyqKr0gG1zsm8kYvBpkUwD4Cd7aoZeuRL7JsDX8nSmUq0h4UEMSzAe9H+/p5aSDZnRyH/YqEmTvrJRrMaIOCTpjN7y/ZTLBbxfR3soyOEwkqc83QcrcuKmz1I0w/F5zCLHha+ww== 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=aBn0FZxDzNsRfNKaFCxWRMxYoI58vkKelQo8FWRPhMc=; b=DDebYlrwhhNv3folvRSW1PdFdaaYBWf/JBPrzDd8tN6r7KTd9vD9twYciuJWMW6kaw/MpERA/B4WpvMU77hF82SwRSAv//I00nk6+nI5jDc9d3NARaIyHDMPHAQnvf3Jf4oRZWiON9+ug9VD4hAiPykeZuDjWsv/Rq10YjSIygyEypM1mFc4sBJc62fH82w+JZTbZ3PFE2pEIxOEzJ3HJeNraMDOokN+MxE8zw7q8m4tWcZQ9UxqASIKr7OybZlrCLRJf4IoOLCSiKWsBDCOAysSa0ejWJwE+Z5UeN6AwZ0JMvnk7NL2qNx0z7ym6AtkfUoF6pqqyZ+qENdWbcpoDw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vodafone.com; dmarc=pass action=none header.from=vodafone.com; dkim=pass header.d=vodafone.com; arc=none x-ms-exchange-crosstenant-network-message-id: 251a3a79-c803-4d63-e9a0-08d79a81ac9a x-ms-exchange-crosstenant-originalarrivaltime: 16 Jan 2020 12:43:23.2017 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: vsX97A60x2KND4lbH3ah6BwVMVT1zEHMMosNUk/WKIjzhw3mF1PGrmQ9hQlkGQmYcRc+aFWwGZfzqNoDWMBleARJSMlEX8q3DezRHXQfnsg= x-ms-exchange-transport-crosstenantheadersstamped: AM0PR05MB4308 Content-Type: multipart/alternative; boundary="_000_AM0PR05MB5730B316E21D5C2FC7240B8C91360AM0PR05MB5730eurp_" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com Archived-At: Subject: Re: [Add] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 16 Jan 2020 12:43:37 -0000 --_000_AM0PR05MB5730B316E21D5C2FC7240B8C91360AM0PR05MB5730eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgYnV0IHdpdGggYW4gYW1lbmRtZW50IGhlcmU6DQoNCiAgICBUaGlzIHdvcmtpbmcgZ3JvdXAg d2lsbCBmb2N1cyBvbiBkaXNjb3ZlcnkgKiwgYXV0aGVudGljYXRpb24qIGFuZCBzZWxlY3Rpb24g b2YgRE5TIHJlc29sdmVycw0KICAgIGJ5IEROUyBjbGllbnRzIGluIGEgdmFyaWV0eSBvZiBuZXR3 b3JraW5nIGVudmlyb25tZW50cywNCg0KVGhpcyBpcyB0byBoZWxwIG1pdGlnYXRlIHRoZSBzY2Vu YXJpbyBvZiBhIHJvZ3VlIHJlc29sdmVyIGluIGEgbG9jYWwgbmV0d29yay4NCg0KQWxsIGJlc3Qs DQpLZXZpbg0KDQoNCg0KDQpDMiBHZW5lcmFsDQpGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgQW5kcmV3IENhbXBsaW5nDQpTZW50OiAxNSBKYW51YXJ5IDIwMjAg MTU6NDUNClRvOiBQYXVsIEFkYWlyIDxwYWRhaXJAaW5mb2Jsb3guY29tPjsgVG9tbXkgUGF1bHkg PHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz47IEdsZW5uIERlZW4gPEdsZW5uX0Rl ZW5AY29tY2FzdC5jb20+OyBBREQgTWFpbGluZyBsaXN0IDxhZGRAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW0FkZF0gVXBkYXRlZCBjaGFydGVyIHByb3Bvc2FsIGZvciBBREQNCg0KKzENCg0KQW5k cmV3DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEFkYWlyIDxwYWRh aXJAaW5mb2Jsb3guY29tPG1haWx0bzpwYWRhaXJAaW5mb2Jsb3guY29tPj4NClNlbnQ6IDE1IEph bnVhcnkgMjAyMCAxMzowNw0KVG86IFRvbW15IFBhdWx5IDx0cGF1bHk9NDBhcHBsZS5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBB REQgTWFpbGluZyBsaXN0IDxhZGRAaWV0Zi5vcmc8bWFpbHRvOmFkZEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW0FkZF0gVXBkYXRlZCBjaGFydGVyIHByb3Bvc2FsIGZvciBBREQNCg0KSSBzdXBw b3J0IHRoZSBjaGFydGVyIGFzIHdyaXR0ZW4uDQoNClBhdWwgQWRhaXINCkluZm9ibG94DQoNCu+7 v09uIDEvMTQvMjAsIDQ6MzggUE0sICJBZGQgb24gYmVoYWxmIG9mIFRvbW15IFBhdWx5IiA8YWRk LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIw dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCiAgICBIaSBhbGws DQoNCiAgICBJIHdhbnRlZCB0byBzaGFyZSBhbiB1cGRhdGVkIHByb3Bvc2FsIGZvciBhbiBBREQg Y2hhcnRlciwgYmFzZWQgb24gdGhlIGZlZWRiYWNrIGFuZCBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0 IGluIHRoZSBwYXN0IHNldmVyYWwgd2Vla3MuDQoNCiAgICBUaGlzIGlzIGJhc2VkIG9uIHRoZSBv cmlnaW5hbCBwcm9wb3NhbCB0aGF0IHdhcyBzZW50IGluIERlY2VtYmVyLCB0YWtpbmcgaW50byBh Y2NvdW50IHZhcmlvdXMgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLiBHbGVubiBEZWVuLCBBbmRy ZXcgQ2FtcGxpbmcsIGFuZCBJIHdvcmtlZCBvbiB0aGlzIHJldmlzaW9uIHRvZ2V0aGVyIGFuZCBj YW1lIHRvIGNvbnNlbnN1cyBvbiBpdHMgY29udGVudHMuDQoNCiAgICBUaG91Z2h0cyBhbmQgY29t bWVudHMgYXJlIHdlbGNvbWUgYXMgYWx3YXlzIQ0KDQogICAgKE5vdGUgdGhhdCB0aGUgcHJvcG9z ZWQgbmFtZSBvZiB0aGUgZ3JvdXAgd2FzIG5vdCBjaGFuZ2VkLCBhbmQgaXMgZW50aXJlbHkgb3Bl biB0byBiaWtlc2hlZGRpbmcuIE5hbWluZyBpcyBoYXJkISkNCg0KICAgIEJlc3QsDQogICAgVG9t bXkNCg0KDQoNCiAgICBBZGFwdGl2ZSBETlMgRGlzY292ZXJ5IChBREQpDQogICAgPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAgUHJvcG9zZWQgV29ya2luZyBHcm91cCBD aGFydGVyDQoNCiAgICBTZW5kaW5nIEROUyBtZXNzYWdlcyBvdmVyIGVuY3J5cHRlZCB0cmFuc3Bv cnRzLCBhcyBkZWZpbmVkIGluIEROUyBvdmVyDQogICAgVExTIChEb1QpIFtSRkMgNzg1OF0gYW5k IEROUyBvdmVyIEhUVFBTIChEb0gpIFtSRkMgODQ4NF0sIHByb3ZpZGVzDQogICAgYmVuZWZpdHMg dG8gdGhlIHNlY3VyaXR5IGFuZCBwcml2YWN5IG9mIEROUyBkYXRhLiBDbGllbnRzLCBzdWNoIGFz DQogICAgYXBwbGljYXRpb25zIGFuZCBob3N0IG9wZXJhdGluZyBzeXN0ZW1zLCBoYXZlIHN0YXJ0 ZWQgYWRvcHRpbmcgdGhlc2UNCiAgICBwcm90b2NvbHMgdG8gcHJvdmlkZSB0aGVzZSB1c2VyIGJl bmVmaXRzLg0KDQogICAgVGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24gZGlzY292ZXJ5 IGFuZCBzZWxlY3Rpb24gb2YgRE5TIHJlc29sdmVycw0KICAgIGJ5IEROUyBjbGllbnRzIGluIGEg dmFyaWV0eSBvZiBuZXR3b3JraW5nIGVudmlyb25tZW50cywgaW5jbHVkaW5nIHB1YmxpYw0KICAg IG5ldHdvcmtzLCBwcml2YXRlIG5ldHdvcmtzLCBhbmQgVlBOczsgc3VwcG9ydGluZyBib3RoIGVu Y3J5cHRlZCBhbmQNCiAgICB1bmVuY3J5cHRlZCByZXNvbHZlcnMuDQoNCiAgICBDbGllbnRzIGFk b3B0aW5nIGVuY3J5cHRlZCBETlMgcHJvdG9jb2xzIG5lZWQgdG8gZGV0ZXJtaW5lIHdoaWNoIERO Uw0KICAgIHNlcnZlcnMgc3VwcG9ydCBlbmNyeXB0ZWQgdHJhbnNwb3J0cywgYW5kIHdoaWNoIHNl cnZlciB0byB1c2UgZm9yIHNwZWNpZmljDQogICAgcXVlcmllcyBpZiBtdWx0aXBsZSBzZXJ2ZXJz IGFyZSBhdmFpbGFibGUuIFRoZXNlIGRlY2lzaW9ucyBjYW4gdmFyeSBiYXNlZA0KICAgIG9uIHRo ZSBuZXR3b3JrIGVudmlyb25tZW50LCBhbmQgYWxzbyBiYXNlZCBvbiB0aGUgY29udGVudCBhbmQg cHVycG9zZSBvZg0KICAgIHRoZSBjbGllbnQgcXVlcmllcy4NCg0KICAgIE5ldHdvcmsgb3BlcmF0 b3JzIHRoYXQgc3RhcnQgb2ZmZXJpbmcgRE5TIGVuY3J5cHRpb24gb24gdGhlaXIgc2VydmVycyBh bHNvDQogICAgbmVlZCBhIHdheSB0byBpbmRpY2F0ZSB0aGlzIHN1cHBvcnQgdG8gY2xpZW50cy4g Q29tbXVuaWNhdGluZyBpbmZvcm1hdGlvbg0KICAgIGFib3V0IHJlc29sdmVyIGNvbmZpZ3VyYXRp b24gYW5kIGJlaGF2aW9yIGFsbG93cyBjbGllbnRzIHRvIG1ha2UgbW9yZQ0KICAgIGluZm9ybWVk IGRlY2lzaW9ucyBhYm91dCB3aGljaCBETlMgc2VydmVycyB0byB1c2UuIEZvciBleGFtcGxlLCBh IHJlc29sdmVyDQogICAgbWF5IGJlIGFibGUgdG8gcmVzb2x2ZSBwcml2YXRlIG9yIGxvY2FsIG5h bWVzIGFzIGEgc3BsaXQgRE5TIHNlcnZlci4NCg0KICAgIFRoZSBBZGFwdGl2ZSBETlMgRGlzY292 ZXJ5IChBREQpIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIG9uIHRoZSBmb2xsb3dpbmcNCiAgICBk ZWxpdmVyYWJsZXM6DQoNCiAgICAtIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBjbGll bnRzIHRvIGRpc2NvdmVyIEROUyByZXNvbHZlcnMsDQogICAgaW5jbHVkaW5nIGVuY3J5cHRlZCBE TlMgc2VydmVycywgdGhhdCBhcmUgYXZhaWxhYmxlIHRvIHRoZSBjbGllbnQNCiAgICBlaXRoZXIg b24gdGhlIHB1YmxpYyBJbnRlcm5ldCBvciBvbiBwcml2YXRlIG9yIGxvY2FsIG5ldHdvcmtzOw0K DQogICAgLSBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgY29tbXVuaWNhdGlvbiBvZiBE TlMgcmVzb2x2ZXINCiAgICBpbmZvcm1hdGlvbiB0byBjbGllbnRzIGZvciB1c2UgaW4gc2VsZWN0 aW9uIGRlY2lzaW9uczsNCg0KICAgIC0gZGV2ZWxvcCBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 IHRoYXQgZGVzY3JpYmVzIGhvdyBjbGllbnQNCiAgICBhcHBsaWNhdGlvbnMgYW5kIHN5c3RlbXMg Y2FuIG1hbmFnZSBzZWxlY3Rpb24gb2YgRE5TIHJlc29sdmVycw0KICAgIGluIHZhcmlvdXMgbmV0 d29yayBlbnZpcm9ubWVudHMgYW5kIHVzZSBjYXNlcy4NCg0KICAgIEFueSBtZWNoYW5pc21zIHRo YXQgc3BlY2lmeSBpbnRlcmFjdGlvbnMgYmV0d2VlbiBjbGllbnRzIGFuZA0KICAgIHNlcnZlcnMg bXVzdCBwcm92aWRlIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIGV4cGVjdGVkIG9mIElFVEYNCiAg ICBwcm90b2NvbHMsIGUuZy4sIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uLCBpbnRlZ3JpdHkg cHJvdGVjdGlvbiwNCiAgICBhbmQgYXV0aGVudGljYXRpb24gd2l0aCBzdHJvbmcgd29yayBmYWN0 b3IuDQoNCiAgICBUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggZG5zb3As IGRvaCwgYW5kIGRwcml2ZSBmb3IgYW55DQogICAgY2hhbmdlcyByZXF1aXJlZCBpbiBETlMgcHJv dG9jb2xzLiBJdCB3aWxsIGFsc28gd29yayB3aXRoIGNhcHBvcnQgdG8NCiAgICBlbnN1cmUgdGhh dCBzb2x1dGlvbnMgYXJlIGFwcGxpY2FibGUgdG8gY2FwdGl2ZSBuZXR3b3Jrcy4NCg0KICAgIC0t DQogICAgQWRkIG1haWxpbmcgbGlzdA0KICAgIEFkZEBpZXRmLm9yZzxtYWlsdG86QWRkQGlldGYu b3JnPg0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FkZF9fOyEhSllzZ1RSQWc2WlEhWUFZV3BxSXotNW1uVktGUDF1 b21hSG5acWFhUGVNN2pnX3QzYjJKRWIxUkdLSUxETXRsdHYxZUQ2OFZEaDNZJDxodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fk ZF9fOyEhSllzZ1RSQWc2WlEhWUFZV3BxSXotNW1uVktGUDF1b21hSG5acWFhUGVNN2pnX3QzYjJK RWIxUkdLSUxETXRsdHYxZUQ2OFZEaDNZJD4NCg0KDQoNCg== --_000_AM0PR05MB5730B316E21D5C2FC7240B8C91360AM0PR05MB5730eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZW1haWxxdW90ZSwgbGku ZW1haWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxxdW90ZTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjEuMHB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpwLm1zaXBmb290ZXI5YWIyOGUy OSwgbGkubXNpcGZvb3RlcjlhYjI4ZTI5LCBkaXYubXNpcGZvb3RlcjlhYjI4ZTI5DQoJe21zby1z dHlsZS1uYW1lOm1zaXBmb290ZXI5YWIyOGUyOTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiYjNDM7MSBidXQgd2l0aCBhbiBhbWVu ZG1lbnQgaGVyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9uIGRpc2NvdmVyeSAq PGI+LCBhdXRoZW50aWNhdGlvbjwvYj4qIGFuZCBzZWxlY3Rpb24gb2YgRE5TIHJlc29sdmVyczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyBieSBETlMgY2xpZW50cyBpbiBhIHZhcmlldHkgb2YgbmV0d29ya2luZyBlbnZpcm9ubWVu dHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMg aXMgdG8gaGVscCBtaXRpZ2F0ZSB0aGUgc2NlbmFyaW8gb2YgYSByb2d1ZSByZXNvbHZlciBpbiBh IGxvY2FsIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5B bGwgYmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+S2V2 aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im1zaXBmb290ZXI5YWIyOGUyOSIgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QzIgR2VuZXJhbDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFkZCAmbHQ7YWRkLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJldyBDYW1wbGluZzxi cj4NCjxiPlNlbnQ6PC9iPiAxNSBKYW51YXJ5IDIwMjAgMTU6NDU8YnI+DQo8Yj5Ubzo8L2I+IFBh dWwgQWRhaXIgJmx0O3BhZGFpckBpbmZvYmxveC5jb20mZ3Q7OyBUb21teSBQYXVseSAmbHQ7dHBh dWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnJmd0OzsgR2xlbm4gRGVlbiAmbHQ7R2xlbm5f RGVlbkBjb21jYXN0LmNvbSZndDs7IEFERCBNYWlsaW5nIGxpc3QgJmx0O2FkZEBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBZGRdIFVwZGF0ZWQgY2hhcnRlciBwcm9wb3Nh bCBmb3IgQUREPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJldzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBQYXVsIEFkYWlyICZsdDs8YSBo cmVmPSJtYWlsdG86cGFkYWlyQGluZm9ibG94LmNvbSI+cGFkYWlyQGluZm9ibG94LmNvbTwvYT4m Z3Q7IDxicj4NClNlbnQ6IDE1IEphbnVhcnkgMjAyMCAxMzowNzxicj4NClRvOiBUb21teSBQYXVs eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZyI+ dHBhdWx5PTQwYXBwbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs7IEFERCBNYWlsaW5nIGxp c3QgJmx0OzxhIGhyZWY9Im1haWx0bzphZGRAaWV0Zi5vcmciPmFkZEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KU3ViamVjdDogUmU6IFtBZGRdIFVwZGF0ZWQgY2hhcnRlciBwcm9wb3NhbCBmb3IgQURE PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SSBzdXBwb3J0IHRoZSBjaGFydGVyIGFzIHdyaXR0ZW4uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ UGF1bCBBZGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkluZm9ibG94PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+77u/T24gMS8xNC8yMCwgNDozOCBQTSwg JnF1b3Q7QWRkIG9uIGJlaGFsZiBvZiBUb21teSBQYXVseSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkZC1ib3VuY2VzQGlldGYub3JnJTIwb24lMjBiZWhhbGYlMjBvZiUyMHRwYXVseT00MGFw cGxlLmNvbUBkbWFyYy5pZXRmLm9yZyI+YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7DQogd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsgSSB3YW50ZWQgdG8gc2hhcmUgYW4gdXBkYXRlZCBwcm9wb3NhbCBmb3IgYW4gQUREIGNo YXJ0ZXIsIGJhc2VkIG9uIHRoZSBmZWVkYmFjayBhbmQgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBp biB0aGUgcGFzdCBzZXZlcmFsIHdlZWtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBU aGlzIGlzIGJhc2VkIG9uIHRoZSBvcmlnaW5hbCBwcm9wb3NhbCB0aGF0IHdhcyBzZW50IGluIERl Y2VtYmVyLCB0YWtpbmcgaW50byBhY2NvdW50IHZhcmlvdXMgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zLiBHbGVubiBEZWVuLCBBbmRyZXcgQ2FtcGxpbmcsIGFuZCBJIHdvcmtlZCBvbiB0aGlzIHJl dmlzaW9uIHRvZ2V0aGVyDQogYW5kIGNhbWUgdG8gY29uc2Vuc3VzIG9uIGl0cyBjb250ZW50cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgVGhvdWdodHMgYW5kIGNvbW1lbnRzIGFyZSB3 ZWxjb21lIGFzIGFsd2F5cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgKE5vdGUgdGhh dCB0aGUgcHJvcG9zZWQgbmFtZSBvZiB0aGUgZ3JvdXAgd2FzIG5vdCBjaGFuZ2VkLCBhbmQgaXMg ZW50aXJlbHkgb3BlbiB0byBiaWtlc2hlZGRpbmcuIE5hbWluZyBpcyBoYXJkISk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgVG9tbXk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgQWRhcHRpdmUgRE5T IERpc2NvdmVyeSAoQUREKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyA9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgUHJvcG9zZWQgV29ya2luZyBH cm91cCBDaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbmRpbmcgRE5TIG1l c3NhZ2VzIG92ZXIgZW5jcnlwdGVkIHRyYW5zcG9ydHMsIGFzIGRlZmluZWQgaW4gRE5TIG92ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVExTIChEb1QpIFtSRkMgNzg1OF0gYW5kIEROUyBvdmVyIEhU VFBTIChEb0gpIFtSRkMgODQ4NF0sIHByb3ZpZGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlbmVm aXRzIHRvIHRoZSBzZWN1cml0eSBhbmQgcHJpdmFjeSBvZiBETlMgZGF0YS4gQ2xpZW50cywgc3Vj aCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbnMgYW5kIGhvc3Qgb3BlcmF0aW5n IHN5c3RlbXMsIGhhdmUgc3RhcnRlZCBhZG9wdGluZyB0aGVzZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyBwcm90b2NvbHMgdG8gcHJvdmlkZSB0aGVzZSB1c2VyIGJlbmVmaXRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyBUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBmb2N1cyBvbiBkaXNjb3Zl cnkgYW5kIHNlbGVjdGlvbiBvZiBETlMgcmVzb2x2ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJ5 IEROUyBjbGllbnRzIGluIGEgdmFyaWV0eSBvZiBuZXR3b3JraW5nIGVudmlyb25tZW50cywgaW5j bHVkaW5nIHB1YmxpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBuZXR3b3JrcywgcHJpdmF0ZSBuZXR3 b3JrcywgYW5kIFZQTnM7IHN1cHBvcnRpbmcgYm90aCBlbmNyeXB0ZWQgYW5kPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IHVuZW5jcnlwdGVkIHJlc29sdmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsgQ2xpZW50cyBhZG9wdGluZyBlbmNyeXB0ZWQgRE5TIHByb3RvY29scyBuZWVkIHRvIGRl dGVybWluZSB3aGljaCBETlM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgc2VydmVycyBzdXBwb3J0IGVu Y3J5cHRlZCB0cmFuc3BvcnRzLCBhbmQgd2hpY2ggc2VydmVyIHRvIHVzZSBmb3Igc3BlY2lmaWM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcXVlcmllcyBpZiBtdWx0aXBsZSBzZXJ2ZXJzIGFyZSBhdmFp bGFibGUuIFRoZXNlIGRlY2lzaW9ucyBjYW4gdmFyeSBiYXNlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyBvbiB0aGUgbmV0d29yayBlbnZpcm9ubWVudCwgYW5kIGFsc28gYmFzZWQgb24gdGhlIGNvbnRl bnQgYW5kIHB1cnBvc2Ugb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGNsaWVudCBxdWVyaWVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBOZXR3b3JrIG9wZXJhdG9ycyB0aGF0IHN0 YXJ0IG9mZmVyaW5nIEROUyBlbmNyeXB0aW9uIG9uIHRoZWlyIHNlcnZlcnMgYWxzbzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyBuZWVkIGEgd2F5IHRvIGluZGljYXRlIHRoaXMgc3VwcG9ydCB0byBjbGll bnRzLiBDb21tdW5pY2F0aW5nIGluZm9ybWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFib3V0 IHJlc29sdmVyIGNvbmZpZ3VyYXRpb24gYW5kIGJlaGF2aW9yIGFsbG93cyBjbGllbnRzIHRvIG1h a2UgbW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBpbmZvcm1lZCBkZWNpc2lvbnMgYWJvdXQgd2hp Y2ggRE5TIHNlcnZlcnMgdG8gdXNlLiBGb3IgZXhhbXBsZSwgYSByZXNvbHZlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyBtYXkgYmUgYWJsZSB0byByZXNvbHZlIHByaXZhdGUgb3IgbG9jYWwgbmFtZXMg YXMgYSBzcGxpdCBETlMgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUg QWRhcHRpdmUgRE5TIERpc2NvdmVyeSAoQUREKSB3b3JraW5nIGdyb3VwIHdpbGwgd29yayBvbiB0 aGUgZm9sbG93aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbGl2ZXJhYmxlczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsgLSBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBhbGxvd3MgY2xp ZW50cyB0byBkaXNjb3ZlciBETlMgcmVzb2x2ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBpbmNs dWRpbmcgZW5jcnlwdGVkIEROUyBzZXJ2ZXJzLCB0aGF0IGFyZSBhdmFpbGFibGUgdG8gdGhlIGNs aWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBlaXRoZXIgb24gdGhlIHB1YmxpYyBJbnRlcm5ldCBv ciBvbiBwcml2YXRlIG9yIGxvY2FsIG5ldHdvcmtzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyAtIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBjb21tdW5pY2F0aW9uIG9mIERO UyByZXNvbHZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBpbmZvcm1hdGlvbiB0byBjbGllbnRzIGZv ciB1c2UgaW4gc2VsZWN0aW9uIGRlY2lzaW9uczs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz cDsgLSBkZXZlbG9wIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgaG93 IGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbnMgYW5kIHN5c3RlbXMgY2Fu IG1hbmFnZSBzZWxlY3Rpb24gb2YgRE5TIHJlc29sdmVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBp biB2YXJpb3VzIG5ldHdvcmsgZW52aXJvbm1lbnRzIGFuZCB1c2UgY2FzZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFueSBtZWNoYW5pc21zIHRoYXQgc3BlY2lmeSBpbnRlcmFjdGlv bnMgYmV0d2VlbiBjbGllbnRzIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2ZXJzIG11c3Qg cHJvdmlkZSB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBleHBlY3RlZCBvZiBJRVRGPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHByb3RvY29scywgZS5nLiwgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24s IGludGVncml0eSBwcm90ZWN0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgYXV0aGVudGlj YXRpb24gd2l0aCBzdHJvbmcgd29yayBmYWN0b3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoaXMgd29ya2luZyBncm91cCB3aWxsIGNvb3JkaW5hdGUgd2l0aCBkbnNvcCwgZG9oLCBh bmQgZHByaXZlIGZvciBhbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgY2hhbmdlcyByZXF1aXJlZCBp biBETlMgcHJvdG9jb2xzLiBJdCB3aWxsIGFsc28gd29yayB3aXRoIGNhcHBvcnQgdG88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsgZW5zdXJlIHRoYXQgc29sdXRpb25zIGFyZSBhcHBsaWNhYmxlIHRvIGNh cHRpdmUgbmV0d29ya3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyBBZGQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Im1haWx0bzpBZGRAaWV0Zi5vcmciPg0KQWRkQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZF9fOyEhSllzZ1RSQWc2WlEhWUFZV3BxSXotNW1u VktGUDF1b21hSG5acWFhUGVNN2pnX3QzYjJKRWIxUkdLSUxETXRsdHYxZUQ2OFZEaDNZJCI+DQpo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hZGRfXzshIUpZc2dUUkFnNlpRIVlBWVdwcUl6LTVtblZLRlAxdW9tYUhuWnFhYVBl TTdqZ190M2IySkViMVJHS0lMRE10bHR2MWVENjhWRGgzWSQ8L2E+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_AM0PR05MB5730B316E21D5C2FC7240B8C91360AM0PR05MB5730eurp_-- From nobody Thu Jan 16 05:10:48 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF68120071 for ; Thu, 16 Jan 2020 05:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOilY1ZRa5X3 for ; Thu, 16 Jan 2020 05:10:40 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100080.outbound.protection.outlook.com [40.107.10.80]) (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 38BCF12006E for ; Thu, 16 Jan 2020 05:10:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bQDvw8M74KRU2GdUXZc0ah7iZsv4WDA79QKJ8SDOo9M/KKWfbd38IbjwDNC1B95d25C0KWz7off3m1mLzQRxxUPckAyrLRCY3n2nTmaVajFyGNoeIfSufW/7MHjYZrndiGQj8lz+deC6zBU2QTPRjgMdUOeMHiaX8zQtPUo6hUfFangdyHXU/t3GI72ykd9/k0YLT8RWk1hFI+o4Jv8DbpW8WbTSPnT8KkFj7hcNglDWIErnlKIgQzuSX3ONsWlQSPW/pC3Ai1bYTVEnyRRT+8nv8oxvLCwOdrX923TL4xQQuc+xizOXKypu+3QWceB6Zmt2itNcidek8387zMYkAg== 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=qucReL6HYdH9AnE1g6IV8VYiv5OpZrnCVALGFD3UZq0=; b=HK4dtXbhGCTgGVkHIH7AHixSBSzsCB2U/vQuzOH+aL6lk2PX8TogrHNPz/XzB5mNsCqm4ExnIPRr/e8ZwpfxgkcaK51yTMb3Hs4e6G8Aq7cYkyOcbIIhID78gdBUdTj/PituTFgSQm5pNXUGQ4CTL/g47kZHDZwMfgCv+a+q/Ctbp4gLfqphwCZ0CcUrhu1Ckt8F4x+KdmZrR5Omn/p1DCzlCxWoAfULkV6rZ6risnogcIeWSha4P+pmZX+lgnLyvMYSogJSxdn1Ml8ba+6HijwRxAD6RaRPmhWqVh5NbM+7gTJzy1buT1pqMBqkRDvSUtRQY6R7jb9lME/XAyl16w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qucReL6HYdH9AnE1g6IV8VYiv5OpZrnCVALGFD3UZq0=; b=jhn5pTRCj/vVf78T4gr4gt7JQNgs2Cuf1NszWQyLzCWJxMmwCg7bh5zLLn0wFYd2punVIXIi+1ccXwzOKUuztzSrOW4Quu2NQOt4/7UDmu1KMcoviZlPDviSNdt2pz5nEV0+zfE2qUsgdlJGnwVTUtJlusmTdIYzLpsaQGwqqyI= Received: from CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM (10.164.145.149) by CWXP265MB0949.GBRP265.PROD.OUTLOOK.COM (20.176.43.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Thu, 16 Jan 2020 13:10:37 +0000 Received: from CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM ([fe80::d74:5246:8470:c587]) by CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM ([fe80::d74:5246:8470:c587%4]) with mapi id 15.20.2623.018; Thu, 16 Jan 2020 13:10:37 +0000 From: Andrew Campling To: Rob Sayre , "Deen, Glenn (NBCUniversal)" CC: Ted Lemon , ADD Mailing list , Brian Dickson , "STARK, BARBARA H" Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy9lqwC/nlKcMjUOTXypYWIN7UafsIFTAgAAFlICAABdDZYAAAa8AgAANaoCAAAHdgIAABiAAgAADM4CAABMagIAA2m7Q Date: Thu, 16 Jan 2020 13:10:37 +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=andrew.campling@419.consulting; x-originating-ip: [89.34.98.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5f9b662-07a6-481e-c1c9-08d79a857ade x-ms-traffictypediagnostic: CWXP265MB0949: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(136003)(376002)(39830400003)(189003)(199004)(8936002)(71200400001)(86362001)(81166006)(2906002)(81156014)(8676002)(186003)(44832011)(66556008)(5660300002)(66476007)(26005)(66946007)(76116006)(66446008)(64756008)(316002)(33656002)(54906003)(6506007)(55016002)(9686003)(508600001)(7696005)(4326008)(110136005)(4744005)(52536014)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:CWXP265MB0949; H:CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2IID37Off2mYyuTKdRWogqVC4kCQtc7TtMvS//VP97Ir/lsBvpolTXErGtfrJgEkDBApKAM22xYJa9CfjA1KQz0rHWQPc2LC6SiTbtb7kjuAZk/S1RZPqTZtFk7tSgjj6fK0R2Kuwp/WrKwKHxL3QuiUR43IdN53sASI5oC9CpaD/H5IqtU3fmDmzSfFc/2/uobxoMcfN57AgfbZ3DdFJBozqqwK2UAbavBwEzwyKNlwfAIVJK30DPLmpdtQbCeml5+OfBHaljRWmIBc1q02iQW4QklJawKDc6ekSMb+Dsoz09xHyx5cBcq/ioyxD2q1g8c6IP0eoRK+KK+5L0B6jAOnkdU/iFSvc4JAKQNd1y3cFfT+PE7Y9gQmMnmvVgPLNsbfUhSTtrhicWxKNp6BtezRjmaqfd5g4XxMuq9PkJ+YTRtb8Ez1JGWYKDZOxsgAiMK6PAXXG0zS0GbjzT9SRaw9uJpc7iikdIFI2Pr7hLE= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CWXP265MB0566FDF1030771C6916BE37AC2360CWXP265MB0566GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: c5f9b662-07a6-481e-c1c9-08d79a857ade X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 13:10:37.8641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7HRL5j0sEgUfWMLhnpArn6Vj5ShNAsHXiXDow/SqHNk+FD3qPnBvmtNvoC69BpG7QJAACQChx+ywMYhvt/m/jRCMO02nAgEdSuWeKJ1wymM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP265MB0949 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 16 Jan 2020 13:10:47 -0000 --_000_CWXP265MB0566FDF1030771C6916BE37AC2360CWXP265MB0566GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVGh1cnMsIEphbiAxNSwgMjAyMCBhdCAwMDowOSBSb2IgU2F5cmUgPHNheXJlckBnbWFpbC5j b20+IHdyb3RlOg0KDQo+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIG91dGxpbmUgdGhlIGludGVy b3BlcmFiaWxpdHkgcHJvYmxlbXMgdGhlIFdHIGFpbXMgdG8gYWRkcmVzcywgZXZlbg0KPiBpZiBp dCdzIG5vdCBpbiB0aGUgY2hhcnRlciBpdHNlbGY/IE9wcG9ydHVuaXN0aWMgZW5jcnlwdGlvbiB3 b3VsZG4ndCBzZWVtIHRvIHJlcXVpcmUgYSBkaXNjb3ZlcnkNCj4gbWVjaGFuaXNtLg0KDQpXb3Vs ZG7igJl0IHRoaXMgYmUgc29tZXRoaW5nIGZvciB0aGUgV0cgdG8gYWdyZWUgb25jZSBjaGFydGVy ZWQ/DQoNCkFuZHJldw0KDQo= --_000_CWXP265MB0566FDF1030771C6916BE37AC2360CWXP265MB0566GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodXJzLCBKYW4gMTUsIDIwMjAgYXQgMDA6MDkgPHNwYW4gbGFuZz0iRU4tVVMiPlJvYiBT YXlyZSAmbHQ7c2F5cmVyQGdtYWlsLmNvbSZndDsNCjwvc3Bhbj53cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFdvdWxkIGl0IGJl IHBvc3NpYmxlIHRvIG91dGxpbmUgdGhlIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgdGhlIFdH IGFpbXMgdG8gYWRkcmVzcywgZXZlbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyA8L3NwYW4+aWYgaXQncyBu b3QgaW4gdGhlIGNoYXJ0ZXIgaXRzZWxmPyBPcHBvcnR1bmlzdGljIGVuY3J5cHRpb24gd291bGRu J3Qgc2VlbSB0byByZXF1aXJlIGEgZGlzY292ZXJ5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IDwvc3Bhbj5t ZWNoYW5pc20uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldvdWxkbuKAmXQgdGhpcyBiZSBzb21ldGhpbmcgZm9yIHRoZSBXRyB0byBhZ3JlZSBv bmNlIGNoYXJ0ZXJlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkFuZHJldyA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CWXP265MB0566FDF1030771C6916BE37AC2360CWXP265MB0566GBRP_-- From nobody Thu Jan 16 05:18:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984F120074 for ; Thu, 16 Jan 2020 05:18:08 -0800 (PST) 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, 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 TEqc0YrpwY2E for ; Thu, 16 Jan 2020 05:18:03 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 EA1D712006E for ; Thu, 16 Jan 2020 05:18:02 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id z14so19011868qkg.9 for ; Thu, 16 Jan 2020 05:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FOa5jAJsNwbcHFQQ3zmgIke3ZHIpb/uytYeCCPNZoC4=; b=kw/vnAyFsVm6TKAh5+ni1h1caf7pzTkIyNDRwwsVceRLttKPt3Whza6VPCkA3BwOEz NuMYGxo4FH65OHjm0copA3uVA13m1zTYiHsR1+V8BnP014W4UBstqo/dN69jyP16hLNb 6aSGsuicQ6fykZV4576iOtxADYArT4x1IsPNYbwYz3c0P/gVp1Cl0HkNtBB4TCRokVP4 clbI1kULFgUv/X4947JM0aO6NeV9TW2tMF0Imq2sl9neUHGVd1E3zAKcXacydEw8+HNb 5Ar73Vo6qAF4Ex1aowZmOCGq0zR+VFkr6U2qqZFfgP3W8TSnBxTz6pHPUJlxDSLyyukN WyvA== 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=FOa5jAJsNwbcHFQQ3zmgIke3ZHIpb/uytYeCCPNZoC4=; b=tmp/6Tlb8QG7gCqkuwbWPvP+32s7G7p076YMFaI57tJjBMTuQgyJeHghc7IAFhp0/G nFU8Y+a1WMs/Z7LTHdc5T4YFuxIyvV7LLoH3S28aE8G8zg/Mgv8osQ7XN/dErqWT0jwz iLn8bevifGZQUVRawX9fC1FVY7JS0KZbScMSDdGmLirmsnIMwyypHnO4t0KNc76z8bWR 2pW+9xmhBM02xKTtRUjXe9u4twfgnNVALy48RNkiVB0O/AZRp0q11WOzM21pC/CmOGsx E4R6Cq6Wqc3jDP1XMWZUExqJ57ve0yZLyunZkaSImI9wkua7MsV2+u2vGH9FtxOTn8DJ b09g== X-Gm-Message-State: APjAAAWuWKZaVoPxD9snQygRZfpQfHY75ZIeD6UeP7YleAEterI5SeHF jQ7VxXtekMwtEmoOvk9XvjNWSg== X-Google-Smtp-Source: APXvYqxBdt8AT6oX05uwt3OLcZPgVshY7ET0lJeHRhPQf0gfq+b170SOc+H6z7wrLuSM3Ozm7XVaJQ== X-Received: by 2002:a37:9a13:: with SMTP id c19mr31951633qke.365.1579180682023; Thu, 16 Jan 2020 05:18:02 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e407:5057:2d90:873e? ([2601:18b:300:36ee:e407:5057:2d90:873e]) by smtp.gmail.com with ESMTPSA id q130sm9971856qka.114.2020.01.16.05.18.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 05:18:01 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_65257A96-863F-4C0A-B16A-D2BB68A706E0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Thu, 16 Jan 2020 08:17:58 -0500 In-Reply-To: Cc: Rob Sayre , "Deen, Glenn (NBCUniversal)" , ADD Mailing list , Brian Dickson , "STARK, BARBARA H" To: Andrew Campling References: X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 16 Jan 2020 13:18:09 -0000 --Apple-Mail=_65257A96-863F-4C0A-B16A-D2BB68A706E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 16, 2020, at 8:10 AM, Andrew Campling = wrote: > Wouldn=E2=80=99t this be something for the WG to agree once chartered? Generally speaking, a tighter charter is better. If it turns out that = the WG discovers it needs to do work that is out of scope, the WG can = recharter, using the new evidence that has been gathered to motivate the = change. We tend to do this poorly in the IETF, unfortunately, so = participants are often unfamiliar with the process=E2=80=A6 :] (FWIW, I happen to think that opportunistic security should be in-scope, = so I=E2=80=99m saying this because your statement was surprising, not = because I don=E2=80=99t want opportunistic security in the charter.) =20= --Apple-Mail=_65257A96-863F-4C0A-B16A-D2BB68A706E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 16, 2020, at 8:10 AM, Andrew Campling <andrew.campling@419.consulting> wrote:
Wouldn=E2=80=99t this be something for the WG to agree = once chartered?

Generally speaking, a tighter charter is better. =   If it turns out that the WG discovers it needs to do work that is = out of scope, the WG can recharter, using the new evidence that has been = gathered to motivate the change.   We tend to do this poorly in the = IETF, unfortunately, so participants are often unfamiliar with the = process=E2=80=A6 :]

(FWIW, I happen = to think that opportunistic security should be in-scope, so I=E2=80=99m = saying this because your statement was surprising, not because I don=E2=80= =99t want opportunistic security in the = charter.)
 
= --Apple-Mail=_65257A96-863F-4C0A-B16A-D2BB68A706E0-- From nobody Fri Jan 17 01:13:08 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705B8120803 for ; Fri, 17 Jan 2020 01:13:07 -0800 (PST) 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 bEHR8APG3T38 for ; Fri, 17 Jan 2020 01:13:06 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFBB120273 for ; Fri, 17 Jan 2020 01:13:06 -0800 (PST) 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 EDA106A266; Fri, 17 Jan 2020 10:13:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1579252384; bh=EPP9Uh+3GVXq8cJdEGZIdIvc5eWb167pqoG6YXiLmTs=; h=Date:From:To:In-Reply-To:References:Subject:From; b=YW8XJwEiMor8e6jGxVDf3zMGDIYRgXbEwlJKPLSHmOihz1AxKsKv/RlOVta/hmgtX ajX9njOcLDznSjAfJF0WJTLhgBcfyVJkJhI2f8lO60A/w4HjmiZKYq+68QYqSwsFAy tRdzysDIunYxZJ/1qZmmrW7dr1zO7nWSZ47KV2aIe6OTjRKHYpRKHklCELXMwEu8TF k0oPnvkFPRixGKSol/rX0m8TIHVs/Yda3/KqcXlVbSa4uRKl4mBKTZQwKIWwLomdMQ jmTUFWNYcaIxBFFuWBkXu7JMKAvthH5tuftB6VxcH6+DaaOONcIrTG9/0ObHq4Fw7E PguUVTgyoAdrA== 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 E20D33C0301; Fri, 17 Jan 2020 10:13:03 +0100 (CET) Date: Fri, 17 Jan 2020 10:13:03 +0100 (CET) From: Vittorio Bertola To: Tommy Pauly , ADD Mailing list Message-ID: <223011059.41195.1579252383830@appsuite-gw1.open-xchange.com> In-Reply-To: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> References: <236B0A34-8C7F-49D2-8075-5AF5AC35BDFB@apple.com> 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.3-Rev3 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] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 17 Jan 2020 09:13:07 -0000 > Il 14/01/2020 23:38 Tommy Pauly ha scritto: > > > Hi all, > > I wanted to share an updated proposal for an ADD charter, based on the feedback and discussion on the list in the past several weeks. I am fine with this charter after removal of the "security properties" paragraph. I'm saying removal rather than rewriting because the attempts to rewrite it seem to be diverging rather than converging; if we absolutely want to write something, I'd suggest that we limit ourselves to stating that opportunistic solutions are also in scope (and that their security properties and possible use cases are to be documented, but AFAIK this is already required of any IETF document). Anything else will just reopen arguments, as it will be seen as an attempt to preempt the results of the discussion. I'm also fine with Jari's second addition if people like it. Personally, I would like to stress that in the end we want the user to be in control of DNS queries, as long as the user thinks to be technically savvy enough for it. Perhaps the third deliverable (the "informational document") should start from there, and describe how "users, client applications and systems" can manage their selections. But this is a minor edit, so I can also live without it. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Jan 17 07:17:05 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604F3120074 for ; Fri, 17 Jan 2020 07:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=ducksong.com header.b=Eanq4Xsg; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=ShPdKh5d Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqDHyv77JL_3 for ; Fri, 17 Jan 2020 07:16:58 -0800 (PST) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 44A9D120018 for ; Fri, 17 Jan 2020 07:16:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579274218; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=SBT8t+eOYaPDucD2mynH76xNTIIcX0Ji6HQyiOy6unbB4ISBzqkcB3huEzH4qmp1Hk5JrRsdIMFa7 zwyyx5BidrpgjvAHsiYOyihBeLd+s2D/GQSshV8NhmpCW0MG9p3mHzFGITrc44O8HO4Pb4RKmzDRLm Nabw72zPYZs+yKMnRBjI34ETP8QsARZMefxHEjroNa+ChvimUgNnbWZrHrqaEja3ioX0I9ahkDT5yq Iu++qsA8Fwh21alBH2rntpjZlrwZ4j9zeyocWvkhhs5QqjXl1/GpVmY1YhQJ9+Azp28cGnWUbyiDIi zOufJYUK0GsLTc3/iNStkWjvHMiWbuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=wBVU2PQGwjPSnCawnzLsRgwtvwcnUwsH+diaKOj1HWA=; b=iGSXm2S8bKEpWiFqw8XiHUAOJHOkhiBNd/tJP6KmDa5Z4f7EtXyhFGiWmr0mywlfFkeCXawwJyc2u RO3o0fs68ARqDqivohcicVvCODUyoGH8HCSS7wYE0etdz+TathIuMB/5BXfL9of/qzjy+55iFXISDx 5JC88QDsHf5B0OwqX1iJlaVCoS/ie/9Vjk+T4zG62PKsdzxq0pvG4gdUNeU60JrZWbPOUB0OpI3wSS APIsogjVcG8KTlkpZpZrHxv9o19kZuLgUP2Tr0nSZ+bV1OQ3xBy3JfNQrfKWYRiL1JWZqF3BvS5We2 /7i1Y4rx4FkCB/7o6NH0il9s36g8NtQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.53; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=wBVU2PQGwjPSnCawnzLsRgwtvwcnUwsH+diaKOj1HWA=; b=Eanq4XsggnMeM6Cb3fy6/Vpaxl8h4srTj9V0FYX7aUm2oXFerBwpheIKveLOrhwq/x/AS91uTYGzL aBnR+14g61h4Dn33KL2eHFamHV/1vt7HFBbQG53pW6cf41KBHTxx/Zrd64VyMkqEejyhkM9FnL3eki lqtIIhOBd4r51j9Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=wBVU2PQGwjPSnCawnzLsRgwtvwcnUwsH+diaKOj1HWA=; b=ShPdKh5dJgb2I7scZHmgBoG8s/oPz3X+azh5vcpx9IgKHLn67Sf0LzcFl1M7ePqGV6qcNGbimbOoh HI+BgTIE3z90YHmGRjO9mkGL/j1P+r377P0F5C4Z+qmq2HQwqhRrj986fJcOKO1BvH8os81iJQDcQ2 dwePkTOib5sagQCxTMUkhvY0Y9taMLsskMycYEPBPyhLcXy9mbGc6POF41XBMZ5mmN0A35CxcHLHvD 4uNY323ZRgr2nWGyAlC4fVerdLXr/g0OFJeV1NmDxgiAXSNKtockmMzFiUuqeKaAKH+Cr9WnvRglHr F6LlCwP8WXwb4QIqDFOzeKwGauQXWfA== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 6643efc7-393c-11ea-9eb3-25e2dfa9fa8d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.53 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f53.google.com (unknown [209.85.210.53]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 6643efc7-393c-11ea-9eb3-25e2dfa9fa8d; Fri, 17 Jan 2020 15:16:57 +0000 (UTC) Received: by mail-ot1-f53.google.com with SMTP id 66so22786877otd.9 for ; Fri, 17 Jan 2020 07:16:56 -0800 (PST) X-Gm-Message-State: APjAAAWtPzL4QtThfsQlDo0Pk+DqO4E1VOQus7neQufI3zm+nhLgHcCd ZHfbE4BNgXEpnj98rGAOeY6OzAiOETngXqld7dQ= X-Google-Smtp-Source: APXvYqyxww7LD1D7RChnWBVBvIA/zsyRRG7MC7LLDD5qECrkI6/A1wEkSyzeBpMVEHPDDnB8NG8eU49eMiPDemeaAoo= X-Received: by 2002:a05:6830:ce:: with SMTP id x14mr6335394oto.289.1579274216105; Fri, 17 Jan 2020 07:16:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Fri, 17 Jan 2020 10:16:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Lemon Cc: Andrew Campling , "STARK, BARBARA H" , "Deen, Glenn (NBCUniversal)" , ADD Mailing list , Brian Dickson , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000a76cae059c576e27" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 17 Jan 2020 15:17:04 -0000 --000000000000a76cae059c576e27 Content-Type: text/plain; charset="UTF-8" Discovery requires authentication - otherwise the encryption is just snake oil security. everyone wants to apply policy (even if the policy is 'unfiltered') and you can't deliver that policy without authentication. And you can't seriously offer confidentiality without authentication either. The proposed charter is clear on this. A charter that allowed the creation of a an unauthenticated "secure" protocol in 2020 would fail to recognize what is possible and really ought to be irrelevant. This, btw, does not rule out unauthenticated network mechanisms (e.g. dhcp or pvd) as transports any more than TLS rules out unauthenticated TCP. It just means you need to layer something else on top if you go that way (e.g. an out of band trust root can sign a connection without caring about the domain name as the webPKI would..) the role of opportunistic is in ratcheting legacy systems forward - this is a new system and should be held to a modern bar. --000000000000a76cae059c576e27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Discovery requires authentication - otherwise the encrypti= on is just snake oil=C2=A0security. everyone wants to apply policy (even if= the policy is 'unfiltered') and you can't deliver that policy = without authentication. And you can't seriously offer confidentiality w= ithout authentication either. The proposed charter is clear on this. A char= ter that allowed the creation of a an unauthenticated "secure" pr= otocol=C2=A0in 2020 would fail to recognize what is possible and really oug= ht to be irrelevant.

This, btw, does not rule out unauth= enticated network mechanisms (e.g. dhcp or pvd) as transports any more than= TLS rules out unauthenticated TCP. It just means=C2=A0you need to layer so= mething else on top if you go that way (e.g. an out of band trust root can = sign a connection without caring about the domain name as the webPKI would.= .)

the role of opportunistic is in ratcheting lega= cy systems forward - this is a new system and should be held to a modern ba= r.
--000000000000a76cae059c576e27-- From nobody Fri Jan 17 07:28:43 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1F612003E for ; Fri, 17 Jan 2020 07:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zxPJe1FA7di1 for ; Fri, 17 Jan 2020 07:28:40 -0800 (PST) Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 19F7B120018 for ; Fri, 17 Jan 2020 07:28:40 -0800 (PST) Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa3.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id 00HFSd29000996 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 17 Jan 2020 15:28:39 GMT Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jan 2020 07:28:37 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.000; Fri, 17 Jan 2020 07:28:37 -0800 From: Paul Hoffman To: ADD Mailing list Thread-Topic: [Add] [Ext] Updated charter proposal for ADD Thread-Index: AQHVy9lmPalt7hxFmk6Gc9Y0XeM6sqfsp62AgAAEV4CAABALAIAABycAgAABwACAAA1rgIAAAdyAgAAGIACAAAMzgIAAExqAgADab4CAAAINAIABs4WAgAADUAA= Date: Fri, 17 Jan 2020 15:28:37 +0000 Message-ID: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_E4CDC4D6-7D86-4600-A0B1-D9E65AA8D408"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-17_03:, , signatures=0 Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 17 Jan 2020 15:28:42 -0000 --Apple-Mail=_E4CDC4D6-7D86-4600-A0B1-D9E65AA8D408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 17, 2020, at 7:16 AM, Patrick McManus = wrote: >=20 > Discovery requires authentication - otherwise the encryption is just = snake oil security. everyone wants to apply policy (even if the policy = is 'unfiltered') and you can't deliver that policy without = authentication. And you can't seriously offer confidentiality without = authentication either. The proposed charter is clear on this. A charter = that allowed the creation of a an unauthenticated "secure" protocol in = 2020 would fail to recognize what is possible and really ought to be = irrelevant. >=20 > This, btw, does not rule out unauthenticated network mechanisms (e.g. = dhcp or pvd) as transports any more than TLS rules out unauthenticated = TCP. It just means you need to layer something else on top if you go = that way (e.g. an out of band trust root can sign a connection without = caring about the domain name as the webPKI would...) >=20 > the role of opportunistic is in ratcheting legacy systems forward - = this is a new system and should be held to a modern bar. This proposal rules out any solution that does not mandate the client = (such as an operating system) having an up-to-date set of cryptographic = trust anchors (such as the web PKI or other crypto initialization by = vendors). It would hobble discovery in many of the common cases that = have been discussed, such as my laptop in my home using my ISP's = resolver. If that type of hobbling is what this group wants, go for it, = but a better approach might be allowing unauthenticated discovery that = can be authenticated by those clients who want to and have the = capability of doing so. --Paul Hoffman= --Apple-Mail=_E4CDC4D6-7D86-4600-A0B1-D9E65AA8D408 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC/Qw ggWeMIIEhqADAgECAhAG83jiXlqePPrfwUUEH4ZnMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xODA2MTMwMDAwMDBaFw0yMTA2 MTMxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxML TG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9uIGZvciBBc3NpZ25lZCBO YW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVUGF1bCBIb2ZmbWFuIDIwMTgwNjEzMSUwIwYJKoZI hvcNAQkBFhZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEArTbxBbfxbk1VxDQsOmEm14Yta2AE5cBcJ/ktMkC+aQrTCMSXrQJfjiMUUndnfAT1DWcf jg706vvITa1lkFaLoF9b6cNICMKsibFruFy8ZA2bsIPRXPPzSsY6zibdStNCpruNTQoiL9bIxlQp qRUx/BfvHAhS7g5dAOcRgkpW9Q4Si5bl6A2qS0ImIMzktNcVxrWAn0HsG9u8cKcSCBJxavRAnMt/ XhE7tCICjyoeoprYZ2ztmdZUL6UgMNrDz/KoeNHAWzTAH45hn1Jz1IguGLM/M2Vb8mF8eP3wAh4p MVIi2jCwNqC497R8x0lsNryoG+uy/26nK6fhCTqVfF6hgQIDAQABo4IB7zCCAeswHwYDVR0jBBgw FoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD+ST5hEHbTuHJZT9husDN7VLQdgMAwG A1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAA7vGiITVJvEIgFN3 UVszD4nyt8ks8d/Ik5Uj1jPuD8+NX4lBpDOIvfYkCn8KYSrx+sMQrpoS2enbOMwekef3tObl2hVK 2Q+tv1GksPq9tQ98Ab1Odv1IM9aYaU1alR5/EEhc0uqs1Ulz2WUc8x/anf3/IpbHyEPdOCLiL9mi b4GDM8z9mqvAE+MtisqRs2+wlMzC/63sNKpA6KdfBNKMLHnyqCAKF7luGWp612yPmGoh63bBLrpR JQorI/fsv5SE2pK3Xf53W/ELf6sxWMsXm9iEgMeoAOtDeJHrv+i+vlldwHHJK6zlXIdVrjxRklyg ISXmlsdHs/sDp1MEqZTOXDCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggMpMIIDJQIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQBvN44l5anjz638FFBB+G ZzANBglghkgBZQMEAgEFAKCCAYEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMTE3MTUyODM3WjAvBgkqhkiG9w0BCQQxIgQgyHd8SEkEYcaTW/0ZMvQE0iM0zUZo c/aXPRclaULVF0kwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrfwUUEH4ZnMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAG83jiXlqePPrf wUUEH4ZnMA0GCSqGSIb3DQEBAQUABIIBAEeVVnxFwLnrHAYUoxTpgiyT76iStJp/9mpsKpYL2A1R BI9qK1dH4V+JWV2n9ROSCyjDZ1aDs5IB0YNgJROWDsCC0taq7mkisY4Hgrv2UluHAf4rsCh0q0vW cmxKtd1jgBhs75Q/lFSPDuwqJzgLodT1saVJmanXSQos33g+Tx1s6pzZ9K/5wNkxwAVwrOUBWSmT snYOjwgjJXsLShl34Hwa5Aj+Fz4rXRmBcdQ82bp/9cgmzHpjBGEMI3H74uqVaJr4x42BZ3rZfzsZ 62cUZlwuIZBQn7NO7CqezV3+Qn+pMlDSrLp59ensERm0HHiGLwN8ZXVdxfiq8H281H9ghuUAAAAA AAA= --Apple-Mail=_E4CDC4D6-7D86-4600-A0B1-D9E65AA8D408-- From nobody Fri Jan 17 09:22:45 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98389120089 for ; Fri, 17 Jan 2020 09:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ducksong.com header.b=Fr4pTBkC; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=d9xYxHpg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmvgXYCx2HlF for ; Fri, 17 Jan 2020 09:22:39 -0800 (PST) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 4710012007A for ; Fri, 17 Jan 2020 09:22:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579281759; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=JVFNTK444a0fPD5MZm7tr7Nk9jWnaAIV/VU4be0CR0aFIAXAFSMfyDEcxweyRj89ABUcxuoO8Oj2y x5ydZCGLhVk1wIiJw1/F/ZxOd+qT6Rj1CLQSJ4uNcjGoEgbSA6DDQrDh8AyxkEl+EpqWqLXH44Ksec E3lUQdG6pWIZtOB4grZJB1eOPMjBBx0FehDCMXd4nSlIh1HmR0FrIYLq5vY44ojqE1S2eR5qQY2yC9 brRKLzbL4LuhoYqetDXBeZSzVw27HZq61do7ve5QWXAoGPL+XdynIx3wacYS0G8TbBTTnak5i5mC6C ayk3mBSYwtrWadafcVTOX6bpaYTWhSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=4Szo4stmxoNUp29LboTMrq7AqQXwevaTunnwfUiJAHU=; b=U08AnKl0A9xKdAPeDRI51ywBaL0Hy4/8p+A/LyAYGXPHLlvh2r5a8YpR9UJykpIlMO5lGbbPrvdr5 IZJTSmNKFoD2y6CFb1hb8H1vcNaMTDsUbNnk4EKzaKTPL7zsJcPaAgFojvuCmsHIn5IPF992xb4jiv 2ZlxlBKC1/mnTn8K2a/zJSjtiN+4Tt8LWGSzxnQruPyurkZ8oux+by4vTSSEaoS4Uj3sbH+WHuRrWs cwuMQytH0bSXXmcZb1oaGitYtkWTDnw77kCBPiKZCV2MS5WreufVDme7MaREZ6onhazK2isd658O2X w5CbnVSU5/OSW3eePhIkhDdIUH0PoOQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.172; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=4Szo4stmxoNUp29LboTMrq7AqQXwevaTunnwfUiJAHU=; b=Fr4pTBkCD6dByBv069r9pFntsG+UFEyXWWGviLfkJm+uN7SgRU+fWBhfvO9grxQr/2w4j10l1rr94 0H3d3CZfXIXoFtCL5F4SnKt618fYbcQiTPxaYDRnb/Eq8r5m/zYK1bwhgbhYdGhGPJ3VkBsV2TMI5r Pm6kdYDaSx9Ztns4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=4Szo4stmxoNUp29LboTMrq7AqQXwevaTunnwfUiJAHU=; b=d9xYxHpgK1233vfHYyEFqKiUvwnpejtVfxLf01NVj4BTV3T0GAGXSgM6p1dLc9bpCZqhl2oAOnhAT VakORhR68EHyE3g/jPTBvDgWyozFzxk+eijGl1JqeSQsR06mG1TV98ujvYVUru5u9ZlevltmL6eYM0 ciNOZaOjL+/cVP6grssdf7k7kbdNgWmuPynXoao4WFAqZD3aZPz7XVi8fd11dG60aQP/JKxJhYmEZy AlAQSIbHFts7QGIodiW1bqjxyVAVaImOLdUv1NIUbfdbuCpUCcAh6cIErajr7E+LcDW2/Cw0p3T7xo HTdpKMYqSRFnd/aCpdyyABB6Td06zIw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: f4d9d989-394d-11ea-b80d-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.172 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f172.google.com (unknown [209.85.167.172]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id f4d9d989-394d-11ea-b80d-052b4a66b6b2; Fri, 17 Jan 2020 17:22:38 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id d62so22799683oia.11 for ; Fri, 17 Jan 2020 09:22:37 -0800 (PST) X-Gm-Message-State: APjAAAXAzoi0GWs13Xdn9KlDV0y3/pnDVIVsrTqLAxf5Y0kpMYOfes7N uCJAgh5VRFgxICt9cW7KnRBiJdXHO5ToJF/rkCY= X-Google-Smtp-Source: APXvYqyN1M3KEU6c/2H0ZQ0Xej1X67M3qD042n4oY3a3NMok4M3Q/nq5pEyEpY3LKg9tsHnQdvcItKEivS8UEY1gcE0= X-Received: by 2002:a05:6808:6d6:: with SMTP id m22mr4037855oih.138.1579281756961; Fri, 17 Jan 2020 09:22:36 -0800 (PST) MIME-Version: 1.0 References: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> In-Reply-To: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> From: Patrick McManus Date: Fri, 17 Jan 2020 12:22:25 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000001fc223059c5930e8" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 17 Jan 2020 17:22:44 -0000 --0000000000001fc223059c5930e8 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 10:28 AM Paul Hoffman wrote: > On Jan 17, 2020, at 7:16 AM, Patrick McManus wrote: > > This proposal rules out any solution that does not mandate the client > (such as an operating system) having an up-to-date set of cryptographic > trust anchors (such as the web PKI or other crypto initialization by > vendors). I would expect the operating system vendor to manage its trust anchors. Using a device that is so out of date that it can't do that isn't giving you any security - so the lack of DoH is hardly its biggest problem. But it would be a giant problem if we built a system that undermined the authenticated properties of DoH for the common case in order to accommodate that. --0000000000001fc223059c5930e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jan 17, 2020 at 10:28 AM Paul Hof= fman <paul.hoffman@icann.org> wrote:
On= Jan 17, 2020, at 7:16 AM, Patrick McManus <mcmanus@ducksong.com> wrote:

This proposal rules out any solution that does not mandate the client (such= as an operating system) having an up-to-date set of cryptographic trust an= chors (such as the web PKI or other crypto initialization by vendors).=C2= =A0

I would expect the operating system ven= dor to manage its trust anchors. Using a device that is so out of date that= it can't do that isn't giving you any security - so the lack of Do= H is hardly its biggest problem. But it would be a giant problem if we buil= t a system that undermined the authenticated properties of DoH for the comm= on case in order to accommodate=C2=A0that.


--0000000000001fc223059c5930e8-- From nobody Fri Jan 17 10:25:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30D71200F1 for ; Fri, 17 Jan 2020 10:25:42 -0800 (PST) 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 01uVqt7Cfcg8 for ; Fri, 17 Jan 2020 10:25:37 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CCA1200F9 for ; Fri, 17 Jan 2020 10:25:21 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id d17so6901344vke.5 for ; Fri, 17 Jan 2020 10:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0xie+KcE/oGBWWA6W8HAKD2nRY6bNNXpdq+xuXrXdA4=; b=qQOkMla0QgJQB0g9n0zUtq19eYTzmDH0QG4iCPracH3gREPatMJyGteiC/qdaXHuqW q3xG97QfkoYfND4PzOo04X7OA858WshR1RWzLf/3SC5M2WZB+c0D18eMmeZhrVLfRzwz P9rD9YKkLtzpqn9n05XWiyjQwCA/nubv9F2+reYhJLUdc/XasCA6rrdAv9cuuk5KZCTy 1f0p3X1hINTHrxaMhKWOdMmf97Q3+6mM8GAGsRg3l07OPmCUZ40WoBahNgggHKjLmBg+ sJfS7bevY0X/3m8B+OQzZdEoApPsIfnp9S8kB8Y9gKz8AD62vfGKa6hk/lbozKU/HsRo 0fSQ== 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=0xie+KcE/oGBWWA6W8HAKD2nRY6bNNXpdq+xuXrXdA4=; b=JrTf/4YpaXX/oYYyQ8u7OcEVvibFDlVYysdTuDvNgHvxhJL/6yXu+r1FSEMuFMSIOj MUFvyUlFaUKqdmB1CHz2O74V4FNf3t7Tv1OonxBF7l2F3Z5Nv+qP2IpD9Y7GiG+y9O3K QA3dL7EDnMFalTd+X22SB0lRvchEO35OfKPzLiQzmMIGP6uuvunltampW6hkNI6shtNH n8tFmJGz0FoAQOuv6UOD/vI4TChwvKvZz4SPvvklB148riibxG1/riv57S9wwZOfrDTd YI/PRaYlZD2UZIWMAcA0Spi3MuLZTt5hFw2gVLnR3zRyLu+X/bv7vIaQEfjNCgEARscj uNBQ== X-Gm-Message-State: APjAAAUGaCWn8MR5ou54Z0NDgBD7dC2ebc2imB8LgOWaEmBQLJH8Z9EK r2Pof4zepSvLsvvfvuY69IVu7IHUPGg3eG2ERJE= X-Google-Smtp-Source: APXvYqzKe+7gjZEaAsZQHH4DRAImE+bqEe5Rq3TlVH6PXTMAKvONJSm509LNsbEynOghL/SoS/sOI0RZaEek4MQsUL0= X-Received: by 2002:a1f:73c6:: with SMTP id o189mr22574422vkc.60.1579285520808; Fri, 17 Jan 2020 10:25:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Fri, 17 Jan 2020 10:25:09 -0800 Message-ID: To: Patrick McManus Cc: Ted Lemon , Andrew Campling , "STARK, BARBARA H" , "Deen, Glenn (NBCUniversal)" , ADD Mailing list , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000778031059c5a109b" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 17 Jan 2020 18:25:43 -0000 --000000000000778031059c5a109b Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 7:16 AM Patrick McManus wrote: > Discovery requires authentication - otherwise the encryption is just snake > oil security. everyone wants to apply policy (even if the policy is > 'unfiltered') and you can't deliver that policy without authentication. And > you can't seriously offer confidentiality without authentication either. > The proposed charter is clear on this. A charter that allowed the creation > of a an unauthenticated "secure" protocol in 2020 would fail to recognize > what is possible and really ought to be irrelevant. > The scope of the proposed charter extends beyond exclusively public resolvers and exclusively web browsers, at least as I read it currently. For the purposes of clarity, we should be careful about the scope of statements such as this, for which I propose some alternate wording for what you wrote. E.g.: "Use of discovered resources which have globally-scoped names requires authentication of those names as part of the protocol being used." I.e. authentication is a "must" IFF the name is an FQDN rooted in the public DNS tree (as served via the IANA root zone). (This would leave open the question of authentication in other environments, which is important for use cases that have been discussed. Obviously any work encompassing those use cases would need to clearly document security and privacy implications of the mechanisms used for authentication.) There is a separate issue is on how identity on public FQDN certificates is authenticated, from a protocol perspective, in terms of what is mandatory to implement (MTI), including dependencies. (Again, this is specifically ONLY about the authentication of resolver identities for establishing the TLS connection from client to resolver, and does not relate to subsequent client behavior in any other context, such as HTTPS generally.) This relates to establishing a privacy-protecting channel from the client to resolver, which arguably is much broader in scope than the privacy attributes for a TLS connection to a single end-point on the WWW. The open question is whether WebPKI (using some set of CAs) should be MTI, or whether use of other validation mechanisms such as DANE TLSA records anchored at the IANA DNS Root Trust Anchor should be MTI? As a point of relevance, IETF standards achieve the greatest degree of interoperability when all necessary parameters are published by (or managed by) IANA. This includes the DNS Root Trust Anchor, and all of the protocol parameter tables. Similarly, at least for the non-CCTLDs, ICANN has an oversight and contractual relationship with registries, and the accreditation of registrars. By contrast, neither ICANN nor IANA are directly involved (at least to my knowledge) in the management or certification of CAs. For the specific purposes of authentication for a "secure" protocol in 2020, is it appropriate to "bake in" the role of CAs and the CA/B to the MTI aspects of the protocol? I think it is something that needs to be taken into consideration in the WG charter. Brian --000000000000778031059c5a109b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 17, 2020 at 7:16 AM Patri= ck McManus <mcmanus@ducksong.com= > wrote:
=
Discovery requires authentication - otherwise the encrypti= on is just snake oil=C2=A0security. everyone wants to apply policy (even if= the policy is 'unfiltered') and you can't deliver that policy = without authentication. And you can't seriously offer confidentiality w= ithout authentication either. The proposed charter is clear on this. A char= ter that allowed the creation of a an unauthenticated "secure" pr= otocol=C2=A0in 2020 would fail to recognize what is possible and really oug= ht to be irrelevant.

The scope of the= proposed charter extends beyond exclusively public resolvers and exclusive= ly web browsers, at least as I read it currently.

= For the purposes of clarity, we should be careful about the scope of statem= ents such as this, for which I propose some alternate wording for what you = wrote.

E.g.:
"Use of discovered res= ources which have globally-scoped names requires authentication of those na= mes as part of the protocol being used."

I.e.= authentication is a "must" IFF the name is an FQDN rooted in the= public DNS tree (as served via the IANA root zone).

(This would leave open the question of authentication in other environme= nts, which is important for use cases that have been discussed. Obviously a= ny work encompassing those use cases would need to clearly document securit= y and privacy implications of the mechanisms used for authentication.)

There is a=C2=A0 separate issue is on how identity on = public FQDN certificates is authenticated, from a protocol perspective, in = terms of what is mandatory to implement (MTI), including dependencies.

(Again, this is specifically ONLY about the authentica= tion of resolver identities for establishing the TLS connection from client= to resolver, and does not relate to subsequent client behavior in any othe= r context, such as HTTPS generally.)

This relates = to establishing a privacy-protecting channel from the client to resolver, w= hich arguably is much broader in scope than the privacy attributes for a TL= S connection to a single end-point on the WWW.

The= open question is whether WebPKI (using some set of CAs) should be MTI, or = whether use of other validation mechanisms such as DANE TLSA records anchor= ed at the IANA DNS Root Trust Anchor should be MTI?

As a point of relevance, IETF standards achieve the greatest degree of in= teroperability when all necessary parameters are published by (or managed b= y) IANA. This includes the DNS Root Trust Anchor, and all of the protocol p= arameter tables.

Similarly, at least for the non-C= CTLDs, ICANN has an oversight and contractual relationship with registries,= and the accreditation of registrars.

By contrast,= neither ICANN nor IANA are directly involved (at least to my knowledge) in= the management or certification of CAs. For the specific purposes of authe= ntication for a "secure" protocol in 2020, is it appropriate to &= quot;bake in" the role of CAs and the CA/B to the MTI aspects of the p= rotocol?

I think it is something that needs to be = taken into consideration in the WG charter.

Brian<= /div>
--000000000000778031059c5a109b-- From nobody Fri Jan 17 18:20:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33BE120059 for ; Fri, 17 Jan 2020 18:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 MOrk85s5uWIA for ; Fri, 17 Jan 2020 18:20:32 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D774120041 for ; Fri, 17 Jan 2020 18:20:32 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id z12so22858160iln.11 for ; Fri, 17 Jan 2020 18:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XYD23Z3HXFH2fjjjn6H7wlmDlR58aqaxsXFZurb04ng=; b=Oh52gqae3O1nA5+sd6uPk4z9rUbY5+ju4faoIGs8mxVhUg1j0T1PtcCZW4rjBACFqW FBjIRhpOWcb64RmT0/OX6MxKEzHRDnJBmCjdjSSyqIErATYxWMdKV7zp1H9VPn2/Qceb GESe+I8DW6Yobug4BhW1l/Z/y3BFZOG9cXaADQANN5rx/lHaL0XGVDbHdH/br9sBglvG 7WeAAr3TqQSMlCuaYxTe80aoliT2gZY5dQBvNP5TBqE1+kP5w/l/0VjxAp7MowIL0GI/ lSKQRYUciyvJZ1OM4ZNgMfoxmGE0DDiK6+YK8Kqidl8O43AM1Vw8GHgxjhQLzAbivO7S cYUQ== 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=XYD23Z3HXFH2fjjjn6H7wlmDlR58aqaxsXFZurb04ng=; b=gwSb6wiDVsE4aBzk6ikI5hqbfJ/Fm3a9PAanXsPvlHDyZjQsszt5dhnWE4jGLlAh51 AAzQuFT9OZQcmYVlCyKduT0M3/bnPL7KkZjzZB+4O12pGyvgmykqEUOXd5+euSGcLGG9 mcUZUX/raQ2KB57izjuUz35AsaIOEfeIWdXbFJefN9f8jYIfT2xp0eRDrdUOe5UszQoM RUCCSRPnCa/4yM0kjhCSCQxw17paxpUccl/fwfV4XiWqlVVi5CB2EucZKXgPOLbQvgRF MNLwylHjKJKo2pPGqaTgEq9qGnsrFqGeenu/kJxTqjFFrPs67PhZ8C+37SXSIirP5zLT ohVg== X-Gm-Message-State: APjAAAVUMcAXlYcPjWkSvNEeKZd3YZLBqZKiZ6Ys0obU89gfZaxaEoJB 5hnYpKi+NPvaygzASJYUhCuHpUBs8CQ1/BE/z4U6SP1IlwY= X-Google-Smtp-Source: APXvYqx+0SQwdO0WSvAyeG/lD0deRnPph981M4vFQn3wNUpEj/c2Tianmro2GNvOQQnqZ1X3LtjNGWo6KGJ5fassY2k= X-Received: by 2002:a92:3b98:: with SMTP id n24mr1334125ilh.189.1579314031823; Fri, 17 Jan 2020 18:20:31 -0800 (PST) MIME-Version: 1.0 References: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> In-Reply-To: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> From: Rob Sayre Date: Fri, 17 Jan 2020 18:20:20 -0800 Message-ID: To: Paul Hoffman Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000db0fc9059c60b3e1" Archived-At: Subject: Re: [Add] [Ext] Updated charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 18 Jan 2020 02:20:34 -0000 --000000000000db0fc9059c60b3e1 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 7:28 AM Paul Hoffman wrote: > > This proposal rules out any solution that does not mandate the client > (such as an operating system) having an up-to-date set of cryptographic > trust anchors (such as the web PKI or other crypto initialization by > vendors). It would hobble discovery in many of the common cases that have > been discussed, such as my laptop in my home using my ISP's resolver. If > that type of hobbling is what this group wants, go for it... > What is the improvement such a group would miss out on? thanks, Rob --000000000000db0fc9059c60b3e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 17, 2020 at 7:28 AM Paul Hoff= man <paul.hoffman@icann.org> wrote:

This proposal rules out any solution that does not mandate the client (such= as an operating system) having an up-to-date set of cryptographic trust an= chors (such as the web PKI or other crypto initialization by vendors). It w= ould hobble discovery in many of the common cases that have been discussed,= such as my laptop in my home using my ISP's resolver. If that type of = hobbling is what this group wants, go for it...
--000000000000db0fc9059c60b3e1-- From nobody Tue Jan 21 05:09:51 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F121200F8 for ; Tue, 21 Jan 2020 05:09:50 -0800 (PST) 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, 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, 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=ericsson.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 jO1QyDiiaOVf for ; Tue, 21 Jan 2020 05:09:44 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2057.outbound.protection.outlook.com [40.107.22.57]) (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 E15AD1200F7 for ; Tue, 21 Jan 2020 05:09:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dCS0823GHKX8M2iZ7QdhSqvY//qC4wYr+f6C2zfcadC5xvh2WsE787rFtiujo2iSRfYj8uFWrzct7YP9vOJhXyXIE2+YrVMFa9uUmQVEqr0Ojk4UaeSjY5M8mDQM6Mxh+st10UWxt/jn9RKwMtaF55A5pWqiiT8DOFl3enE8EZa7EUsfGajClHlo8GXbzlwnS/u8WpTniYGZOSinPNbq3LsrV+sENUjU8hGsqzCMZGP+XqYI/oqqldas4FMhuRToOmpkKYT4fFrc32i4FzqH6lak00DzskBEEvYKNzRislZVk6Ym8UZ7JWhV/d4G0RlhzPMTbks96fye+jedkZIF7Q== 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=1dbovBfP5uYYJYwYFUI0Sn6uCLoxer8EsZZVgscupDo=; b=iUsI9c+VWaBtR+5pwCXr7bAX/lfb2kcIf2CylqNPZBmuUwop9119ahOulVQ7jhqnGJ65QS2Rxqa5BN2gQ8gUzSjuAJ58pYdLDZJw/ErhocwaXzZtGLInku97sOBAyklTAjoRzwBVwQrbl2TrUg4UsitxedIfD0eBPUIyoJ61n7z93IR+742DVHjZ1mocbp76jqG868DmfD6W3VxVYqC0IpMmm0SwlAYiNyWvk2Wg9Ed9Xt7TpxsBxaMo+3vVXiGbg+g1YB6+P3Y5rTToVpGUOzQqAAjtYNw6coUR1XdouYRTuJEZptpkM9c023KSBZu4OqFc25HrRrULQQd6RG0WWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1dbovBfP5uYYJYwYFUI0Sn6uCLoxer8EsZZVgscupDo=; b=Dx1KRrAA3wc0PTUE9gyHFU5iLVqxJCnhWCLp1JJaiQAZSwu//zI3dFGg/wyurur2yzudHgEtQljMKHj+hO1xQGqyfDxgE7KKXirhGe5aKjUXq2jByac5xpNvViAXMO08EuztFA8b1YHWANOj7ITO98uesd/SOJKOcYOrlaH2Bxg= Received: from DB6PR0701MB2904.eurprd07.prod.outlook.com (10.168.84.145) by DB6PR0701MB2982.eurprd07.prod.outlook.com (10.168.84.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.15; Tue, 21 Jan 2020 13:09:41 +0000 Received: from DB6PR0701MB2904.eurprd07.prod.outlook.com ([fe80::69fa:e9b6:4a20:3ede]) by DB6PR0701MB2904.eurprd07.prod.outlook.com ([fe80::69fa:e9b6:4a20:3ede%8]) with mapi id 15.20.2665.015; Tue, 21 Jan 2020 13:09:41 +0000 From: Mohit Sethi M To: "add@ietf.org" Thread-Topic: Food for thought? Thread-Index: AQHV0FwKeynJ3E29vUysvwsKOw+95Q== Date: Tue, 21 Jan 2020 13:09:41 +0000 Message-ID: <9c261636-a030-6116-098d-ac89b1227bad@ericsson.com> References: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:140:3307:cc1e:8406:7a73:dca9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5d3b1ae-4293-4636-8fa5-08d79e732d82 x-ms-traffictypediagnostic: DB6PR0701MB2982: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(396003)(376002)(346002)(39860400002)(189003)(199004)(53546011)(6506007)(71200400001)(86362001)(186003)(3480700007)(2906002)(31696002)(6486002)(64756008)(76116006)(66556008)(316002)(66476007)(66946007)(7116003)(66446008)(2616005)(81166006)(8936002)(36756003)(8676002)(81156014)(966005)(6512007)(31686004)(5660300002)(478600001)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2982; H:DB6PR0701MB2904.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gUjt23wlVmgHCMtUi72hAD2/03vjsPR0tYgfY07GbHMeg/3DHiyTYO8u5eQ2qt2gqNZs+f5pDiEupp0umqLadf1qldDTLXAnxX3d8tAYvX/CvrytbBw3pzNIPa/wca7Ml6XPNd8PRRN5JUX6IVCzow5puk0Vm5qjn4GxvsYlwYQU/7t85TUdAphT43TOFTCjI7kci+h9EWArx7UhUIjGlBgTn7N6CjvmOstlx6vkaIvYRStxpNJ7mFFIRyUG+NPW+FB4FQVU7jSCZ3hFhjKzaDM6B7ijyjAG4Ahuhek8kbc66VTRWenyG/hQL8axTT8X3mHirdFBXUZFs6P4gw7eytePd1pFKPec/+t5q57m8/cEQHBJdR/+rkLOFOBW3se7dMCLVuoBPsMENjaUnCTe+Uagtpf7W+ORlglHLxb+JHM3tXrGRprudkNQlt0cSuqSUFAQlugFIkuTxjIqzuf39jFvJyVj0yaD0pA+SLeE4TtY1NeBvrA0bPU/0Zv/7MWsijrGyXVlPiZaSE/t0HqYog== x-ms-exchange-antispam-messagedata: ZZSLj+WLx9+YGRqvgf2zr+wCWb9qK6GMxBYBPhQz5G34Gz/TLmD5CUVNx9HrRSPv4iXWg6aQwodByFlA7q+Yfa5wnONLweZKsApIkOoz0aAhYz3iwrfcioDvIr3hY2xI+sN+dQXsifvqc61hzIDKbOQ1EN7Z+WeZ9APn6UF0gKiFiQ81qF0WJYfN3ymHXXNOgKdCHsqRNoIoYl+PTC7TJQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9c261636a0306116098dac89b1227badericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5d3b1ae-4293-4636-8fa5-08d79e732d82 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 13:09:41.7273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nOO2+8xNZZP3H6/IOWNaNg5JpK///zGLd6rjpK+4r07lOO1nGG2JkWdU2FbjpZwSJAPIqoUnmtOa2NW2Q1rdA1dc0hHppNMtOssCyyPl1BA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2982 Archived-At: Subject: [Add] Food for thought? X-BeenThere: add@ietf.org X-Mailman-Version: 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, 21 Jan 2020 13:09:50 -0000 --_000_9c261636a0306116098dac89b1227badericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHRvb2sgdGltZSB0byBzdHVkeSBzb21lIG9mIHRoZSBlbWFpbCBkaXNjdXNz aW9uIChhbGJlaXQgbm90IGFsbCkuIEkgbWFkZSBzdXJlIHRvIGNhcmVmdWxseSByZWFkIHRoZSBw cm9wb3NlZCBjaGFydGVyIHRleHQgd3JpdHRlbiBieSBUb21teTogaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9hZGQveUZPc2RUT2Y2VmZOenNIUFVidUZmUTVVUnp3Lg0KDQpB cyBzZWN1cml0eSBmb2xrcywgbWFueSBvZiB1cyBpbmFkdmVydGVudGx5IHNvbHZlIG91ciBwcm9i bGVtcyBieSBtYWtpbmcgdGhlbSBzb21lb25lIGVsc2Uncy4gQSB2ZXJ5IG5haXZlIGV4YW1wbGUg b2YgdGhpcyB3b3VsZCBiZSB0aGF0IHdlIHNvbHZlZCB0aGUga2V5IGV4Y2hhbmdlIHByb2JsZW0g b2Ygc3ltbWV0cmljIGtleXMgYnkgbWFraW5nIGl0IGEga2V5IGRpc3RyaWJ1dGlvbiBwcm9ibGVt IHdpdGggcHVibGljLWtleSBjcnlwdG9ncmFwaHkuIEkga25vdyB0aGF0IHdlIHNob3VsZG4ndCBy ZWFsbHkgZGlzY3VzcyBzb2x1dGlvbnMgd2hlbiBmb3JtdWxhdGluZyB0aGUgY2hhcnRlci4gSG93 ZXZlciwgSSBzdWdnZXN0IHRoYXQgd2UgdXNlIHRoaXMgb3Bwb3J0dW5pdHkgdG8gZGlzY3VzcyB0 aGUgc3RhcnRpbmcgYXNzdW1wdGlvbnMgZm9yIGEgY2xpZW50IHRvIHNlY3VyZWx5IGRpc2NvdmVy IEROUyByZXNvbHZlcnMuDQoNClNvbWUgb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyB0aGF0IEkg bG9va2VkIGF0IHJlbHkgb24gYW4gYW5vdGhlciB0cnVzdGVkIHNlcnZlciBpbiB0aGUgbmV0d29y ayB0byBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IEROUyByZXNvbHZlcnMuIEFuZCBob3cgZG8g SSBkaXNjb3ZlciB0aGF0IHRydXN0ZWQgc2VydmVyPywgd2VsbCBvZi1jb3Vyc2UsIG1ETlMuIEkg d291bGQgbGlrZSB1cyB0byBzb2x2ZSByZWFsIHByb2JsZW1zIGFuZCBub3QgbWFrZSBjeWNsaWNh bCBkZXBlbmRlbmNpZXMgKGtub3dpbmcgdGhhdCBzb2x2aW5nIHJlYWwgcHJvYmxlbXMgaXMgaGFy ZCBhbmQgdGltZS1jb25zdW1pbmcpLiBJIHdvdWxkIGFsc28gbGlrZSB0byB1bmRlcnN0YW5kIHdo YXQgdHlwZSBvZiBuZXR3b3JrcyBhcmUgaW4gc2NvcGU/IEFzc3VtaW5nIGEgdHJ1c3RlZCBzZXJ2 ZXIgaW4gdGhlIGxvY2FsIG5ldHdvcmsgdG8gaW5mb3JtIG1lIGFib3V0IGNhbmRpZGF0ZSBETlMg cmVzb2x2ZXJzIGlzIGNlcnRhaW5seSBub3QgbGlrZWx5IGluIG1hbnkvbW9zdCBob21lIG5ldHdv cmtzPw0KDQotLU1vaGl0DQoNCk9uIDEvMTgvMjAgNDoyMCBBTSwgUm9iIFNheXJlIHdyb3RlOg0K T24gRnJpLCBKYW4gMTcsIDIwMjAgYXQgNzoyOCBBTSBQYXVsIEhvZmZtYW4gPHBhdWwuaG9mZm1h bkBpY2Fubi5vcmc8bWFpbHRvOnBhdWwuaG9mZm1hbkBpY2Fubi5vcmc+PiB3cm90ZToNCg0KVGhp cyBwcm9wb3NhbCBydWxlcyBvdXQgYW55IHNvbHV0aW9uIHRoYXQgZG9lcyBub3QgbWFuZGF0ZSB0 aGUgY2xpZW50IChzdWNoIGFzIGFuIG9wZXJhdGluZyBzeXN0ZW0pIGhhdmluZyBhbiB1cC10by1k YXRlIHNldCBvZiBjcnlwdG9ncmFwaGljIHRydXN0IGFuY2hvcnMgKHN1Y2ggYXMgdGhlIHdlYiBQ S0kgb3Igb3RoZXIgY3J5cHRvIGluaXRpYWxpemF0aW9uIGJ5IHZlbmRvcnMpLiBJdCB3b3VsZCBo b2JibGUgZGlzY292ZXJ5IGluIG1hbnkgb2YgdGhlIGNvbW1vbiBjYXNlcyB0aGF0IGhhdmUgYmVl biBkaXNjdXNzZWQsIHN1Y2ggYXMgbXkgbGFwdG9wIGluIG15IGhvbWUgdXNpbmcgbXkgSVNQJ3Mg cmVzb2x2ZXIuIElmIHRoYXQgdHlwZSBvZiBob2JibGluZyBpcyB3aGF0IHRoaXMgZ3JvdXAgd2Fu dHMsIGdvIGZvciBpdC4uLg0KDQpXaGF0IGlzIHRoZSBpbXByb3ZlbWVudCBzdWNoIGEgZ3JvdXAg d291bGQgbWlzcyBvdXQgb24/DQoNCnRoYW5rcywNClJvYg0KDQoNCg== --_000_9c261636a0306116098dac89b1227badericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <29090C6313E39F488BDC64BEAFA469B1@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgYWxsLDxi cj4NCjwvcD4NCjxwPkkgdG9vayB0aW1lIHRvIHN0dWR5IHNvbWUgb2YgdGhlIGVtYWlsIGRpc2N1 c3Npb24gKGFsYmVpdCBub3QgYWxsKS4gSSBtYWRlIHN1cmUgdG8gY2FyZWZ1bGx5IHJlYWQgdGhl IHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCB3cml0dGVuIGJ5IFRvbW15Og0KPGEgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Fk ZC95Rk9zZFRPZjZWZk56c0hQVWJ1RmZRNVVSenciPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9hZGQveUZPc2RUT2Y2VmZOenNIUFVidUZmUTVVUnp3PC9hPi4gPGJyPg0K PC9wPg0KPHA+QXMgc2VjdXJpdHkgZm9sa3MsIG1hbnkgb2YgdXMgaW5hZHZlcnRlbnRseSBzb2x2 ZSBvdXIgcHJvYmxlbXMgYnkgbWFraW5nIHRoZW0gc29tZW9uZSBlbHNlJ3MuIEEgdmVyeSBuYWl2 ZSBleGFtcGxlIG9mIHRoaXMgd291bGQgYmUgdGhhdCB3ZSBzb2x2ZWQgdGhlIGtleSBleGNoYW5n ZSBwcm9ibGVtIG9mIHN5bW1ldHJpYyBrZXlzIGJ5IG1ha2luZyBpdCBhIGtleSBkaXN0cmlidXRp b24gcHJvYmxlbSB3aXRoIHB1YmxpYy1rZXkgY3J5cHRvZ3JhcGh5Lg0KIEkga25vdyB0aGF0IHdl IHNob3VsZG4ndCByZWFsbHkgZGlzY3VzcyBzb2x1dGlvbnMgd2hlbiBmb3JtdWxhdGluZyB0aGUg Y2hhcnRlci4gSG93ZXZlciwgSSBzdWdnZXN0IHRoYXQgd2UgdXNlIHRoaXMgb3Bwb3J0dW5pdHkg dG8gZGlzY3VzcyB0aGUgc3RhcnRpbmcgYXNzdW1wdGlvbnMgZm9yIGEgY2xpZW50IHRvIHNlY3Vy ZWx5IGRpc2NvdmVyIEROUyByZXNvbHZlcnMuDQo8YnI+DQo8L3A+DQo8cD5Tb21lIG9mIHRoZSBw cm9wb3NlZCBzb2x1dGlvbnMgdGhhdCBJIGxvb2tlZCBhdCByZWx5IG9uIGFuIGFub3RoZXIgdHJ1 c3RlZCBzZXJ2ZXIgaW4gdGhlIG5ldHdvcmsgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCBE TlMgcmVzb2x2ZXJzLiBBbmQgaG93IGRvIEkgZGlzY292ZXIgdGhhdCB0cnVzdGVkIHNlcnZlcj8s IHdlbGwgb2YtY291cnNlLCBtRE5TLiBJIHdvdWxkIGxpa2UgdXMgdG8gc29sdmUgcmVhbCBwcm9i bGVtcyBhbmQgbm90DQogbWFrZSBjeWNsaWNhbCBkZXBlbmRlbmNpZXMgKGtub3dpbmcgdGhhdCBz b2x2aW5nIHJlYWwgcHJvYmxlbXMgaXMgaGFyZCBhbmQgdGltZS1jb25zdW1pbmcpLiBJIHdvdWxk IGFsc28gbGlrZSB0byB1bmRlcnN0YW5kIHdoYXQgdHlwZSBvZiBuZXR3b3JrcyBhcmUgaW4gc2Nv cGU/IEFzc3VtaW5nIGEgdHJ1c3RlZCBzZXJ2ZXIgaW4gdGhlIGxvY2FsIG5ldHdvcmsgdG8gaW5m b3JtIG1lIGFib3V0IGNhbmRpZGF0ZSBETlMgcmVzb2x2ZXJzIGlzIGNlcnRhaW5seQ0KIG5vdCBs aWtlbHkgaW4gbWFueS9tb3N0IGhvbWUgbmV0d29ya3M/PGJyPg0KPC9wPg0KPHA+LS1Nb2hpdDxi cj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMS8xOC8yMCA0OjIwIEFN LCBSb2IgU2F5cmUgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj aXRlPSJtaWQ6Q0FDaHI2U3lVS212QVE4bmlQWWpRbUw0RVJFWTdjNmRxcXNqcC1NMmJ0NGFfaS1M NDBBQG1haWwuZ21haWwuY29tIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBkaXI9Imx0ciI+T24g RnJpLCBKYW4gMTcsIDIwMjAgYXQgNzoyOCBBTSBQYXVsIEhvZmZtYW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwYXVsLmhvZmZtYW5AaWNhbm4ub3JnIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPnBhdWwu aG9mZm1hbkBpY2Fubi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweA0KICAgICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk DQogICAgICAgICAgICByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0K VGhpcyBwcm9wb3NhbCBydWxlcyBvdXQgYW55IHNvbHV0aW9uIHRoYXQgZG9lcyBub3QgbWFuZGF0 ZSB0aGUgY2xpZW50IChzdWNoIGFzIGFuIG9wZXJhdGluZyBzeXN0ZW0pIGhhdmluZyBhbiB1cC10 by1kYXRlIHNldCBvZiBjcnlwdG9ncmFwaGljIHRydXN0IGFuY2hvcnMgKHN1Y2ggYXMgdGhlIHdl YiBQS0kgb3Igb3RoZXIgY3J5cHRvIGluaXRpYWxpemF0aW9uIGJ5IHZlbmRvcnMpLiBJdCB3b3Vs ZCBob2JibGUgZGlzY292ZXJ5IGluIG1hbnkgb2YNCiB0aGUgY29tbW9uIGNhc2VzIHRoYXQgaGF2 ZSBiZWVuIGRpc2N1c3NlZCwgc3VjaCBhcyBteSBsYXB0b3AgaW4gbXkgaG9tZSB1c2luZyBteSBJ U1AncyByZXNvbHZlci4gSWYgdGhhdCB0eXBlIG9mIGhvYmJsaW5nIGlzIHdoYXQgdGhpcyBncm91 cCB3YW50cywgZ28gZm9yIGl0Li4uPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+V2hhdCBpcyB0aGUgaW1wcm92ZW1lbnQgc3VjaCBhIGdyb3VwIHdvdWxkIG1pc3Mg b3V0IG9uPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+dGhhbmtzLDwvZGl2Pg0KPGRp dj5Sb2ImbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9 Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PiA8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_9c261636a0306116098dac89b1227badericssoncom_-- From nobody Wed Jan 22 05:50:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D311200F4 for ; Wed, 22 Jan 2020 05:50:58 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 L9sJNTrqhnpT for ; Wed, 22 Jan 2020 05:50:55 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10047.outbound.protection.outlook.com [40.107.1.47]) (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 2C7D41200E9 for ; Wed, 22 Jan 2020 05:50:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z0MO1bv+gmpQfflboqR6aIThm76CZwjMtl0HxWf8SuPiHRKZsbIIdPWws7EiIo+Cv52lyLIJhGutf5jAcwrnlU7ZUCP1iqRI7cwEQHDYrIbD4KGn+IGxdxDevc8td0vlmS31Ah05jYmEn/lls+mqRcMj8Zmre32GAIGRj3Gg6iQAeUoTFzOspwkzxlinUX+YurDRKRrYCewD8b8Ox2otBPjLx/ba8LmGqh1x+0BcG5FPxzS4Ds6y8fvEVdHJFO765y6ZDUnLLJZQIKrEFXyaoibdNanNQiQP2OgtmgcpAwrKmdjmILvVBwIN3rGZEbnZGYApAY2SCdrPJAN6ZaDWFw== 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=uCv+KQLnFDbSt5pEhMvgA+iNeK9gZS7r+MEuO3LDkjA=; b=f+MA3tudGNq9ckzl2VcPTlhZasAQz6VmFbb1bga5pxtkymynqKiJb8F8ZhR7MsQ9CRpXgMmdOUQ3JxRF3RdeciimXoZ45fVZHd0CGx1HJBFgz+crUCxxPYyPGJwWPy0pItyI4cQmPGZa0IGQjHX04GPwIfaUFYXgKdhEBDtyjg1B9UPjt6UueS9DfOSkV5hc2DPpV0waUGGF4uHFrjJE7dHBaf40LxGQY+TS4rWWP1fAo+T4jKOfsFEaqB72yMycZeWCkR8krTiVk8Me7lgr+cTq8TuloEww2nR5l+FhYoWBXFsCaI+k9sn0U34wj1rRI6hR5EGg6kVeerJyWO4YGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uCv+KQLnFDbSt5pEhMvgA+iNeK9gZS7r+MEuO3LDkjA=; b=ZcDPOSlCGmKifgjeFCQKql5kQ9NsMtt9ebBMIpCl+YcXTCveAC7OM4dCPqjPlH7fgFQe4qNWglwniXg4SOSXc4oJ6l0VXw2uB3Els64btjIO83beJ48EW3ouTidRMwSGzbNPStQgJ6E4DEaU9r4hct9sRGvjTi2CZwE/+Vflc5Q= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB3051.eurprd07.prod.outlook.com (10.168.98.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Wed, 22 Jan 2020 13:50:52 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c%10]) with mapi id 15.20.2686.008; Wed, 22 Jan 2020 13:50:52 +0000 From: Mohit Sethi M To: Mohit Sethi M , "add@ietf.org" Thread-Topic: [Add] Food for thought? Thread-Index: AQHV0FwKeynJ3E29vUysvwsKOw+95af2tTKA Date: Wed, 22 Jan 2020 13:50:52 +0000 Message-ID: <03037960-e9a7-3dd5-7009-3c79e589fd08@ericsson.com> References: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> <9c261636-a030-6116-098d-ac89b1227bad@ericsson.com> In-Reply-To: <9c261636-a030-6116-098d-ac89b1227bad@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:140:3307:cc1e:8406:7a73:dca9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 858bf54c-7089-4857-f90d-08d79f421886 x-ms-traffictypediagnostic: HE1PR0701MB3051: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(199004)(5660300002)(36756003)(966005)(66574012)(6486002)(76116006)(8676002)(71200400001)(316002)(478600001)(6512007)(66476007)(66446008)(53546011)(64756008)(81166006)(81156014)(86362001)(186003)(6506007)(8936002)(66556008)(2616005)(66946007)(31696002)(31686004)(2906002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3051; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TwvnJt6eotGmCs91fpjo8q901DojEz8IEzNeyH2djG+CzhGPxwXDuHPZqFLYVuxtFMABIqQxErsRejjrC1mPlwZWJQryaeBBImC1xQkk2vzDKCtuITabvdswZZE8L31T+G0jbtfpW/361eu1Z8+Gx8fv3EHUUl3GpFmNkLi6RMLudbKQJfuKtzC1ohtKkamT495ng/RZqEq9iLrPVvuR/qMQ9GhWR0oihhKpGYPkYKkCt7/Y28j9/uNGi0ubM8/huOuPq/jkVQDJHNiVsSX4fG9Q6/2EbrTuIFj5KI22o8LL0j43JlFMSc5x54YR7ulwXs7ykUC0xtSgbfCfTwkhpIe+0q+e+V5EV01i3hPx1dLf9wUghXGrozciaqkw4DwL53ngzLXM9c9ADLk3zKmjmEudXmBNGrINa8iO30UEUdtp8t7JCGhtLiABydwXBbUJzq/zJVXocVsaegNo2FS+VziV82vMYuA2Ta3kKohkZWE= x-ms-exchange-antispam-messagedata: yL1IvwisNbk70CchSCEf2gGsxW8cxeTCV+ywWQGwUNzCvMDsUDxepDhgVvqPBwO/T2/slv7bRsCSFIVGo3kTd5f/pShf86GazPoh47nRjuMBgHGFEE0WjkfPQpPrrlq4Yc504QRL/t2KP1XRi8RG9J/IiaJ9Vf+HgYqr6tHL54J2VM+RIU0rnGtTi5SDWzW3vWSPH13s1+vBSh3qEQNNhw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_03037960e9a73dd570093c79e589fd08ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 858bf54c-7089-4857-f90d-08d79f421886 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 13:50:52.3191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DYtTFVKMqyMELCfy+FkRfRKRQwPCimFHXtUp+lyWGnPaAbL7dlB/vspMBM9SXNwUfYnZPW5z1Wghy2K2EK2jHqYV8DJtGJlXU4NuZyqf9Zw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3051 Archived-At: Subject: Re: [Add] Food for thought? X-BeenThere: add@ietf.org X-Mailman-Version: 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, 22 Jan 2020 13:50:59 -0000 --_000_03037960e9a73dd570093c79e589fd08ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgY29tbWVudCBtYXliZSBzb21ld2hhdCBtaXNsZWFkaW5nIGFuZCBtaWdodCBiZSBpbnRlcnBy ZXRlZCBhcyBpZiBJIGFtIGFnYWluc3QgZm9ybWluZyB0aGlzIHdvcmtpbmcgZ3JvdXAuIFRoYXQg aXMgY2VydGFpbmx5IG5vdCB0aGUgY2FzZS4gSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHdvcmtp bmcgZ3JvdXAgZm9ybWVkIGFuZCB3b3VsZCBiZSBoYXBweSB0byByZXZpZXcvY29udHJpYnV0ZSBh cyB3ZSBwcm9jZWVkLg0KDQpBcyBhIG1vcmUgY29uY3JldGUgc3VnZ2VzdGlvbiwgcGVyaGFwcyB0 aGUgZm9sbG93aW5nIGJ1bGxldCBpbiB0aGUgY3VycmVudCBjaGFydGVyIHRleHQgY291bGQgYmUg YmV0dGVyIGV4cGxhaW5lZDoNCg0KDQotIGRlZmluZSBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBj bGllbnRzIHRvIGRpc2NvdmVyIEROUyByZXNvbHZlcnMsDQppbmNsdWRpbmcgZW5jcnlwdGVkIERO UyBzZXJ2ZXJzLCB0aGF0IGFyZSBhdmFpbGFibGUgdG8gdGhlIGNsaWVudA0KZWl0aGVyIG9uIHRo ZSBwdWJsaWMgSW50ZXJuZXQgb3Igb24gcHJpdmF0ZSBvciBsb2NhbCBuZXR3b3JrczsNCg0KUmF0 aGVyIHRoYW4gZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBwcml2YXRlL2xvY2FsIG5ldHdvcmtzIHZz LiBJbnRlcm5ldCwgaXQgY291bGQgZGlzdGluZ3Vpc2ggaG9tZS9lbnRlcnByaXNlIG5ldHdvcmtz IG9yIHdoZXRoZXIgaW5mcmFzdHJ1Y3R1cmUgaXMgYXZhaWxhYmxlIHRvIGFpZCB0aGUgZGlzY292 ZXJ5IG9yIG5vdC4gRm9yIGV4YW1wbGUsIHNvbWUgZW50ZXJwcmlzZSBuZXR3b3JrcyBtYXkgaGF2 ZSBzZXJ2ZXJzIChzdWNoIGFzIGEgV2luZG93cyBBY3RpdmUgRGlyZWN0b3J5IERvbWFpbiBTZXJ2 aWNlKSB0byBoZWxwIGFzc2lzdCBpbiB0aGUgZGlzY292ZXJ5IG9mIEROUyByZXNvbHZlcnMuIFRo aXMgd291bGQgbm90IGJlIHBvc3NpYmxlIGluIG1hbnkgaG9tZSBuZXR3b3JrcyBvbiB0aGUgb3Ro ZXIgaGFuZC4NCg0KLS1Nb2hpdA0KDQpPbiAxLzIxLzIwIDM6MDkgUE0sIE1vaGl0IFNldGhpIE0g d3JvdGU6DQoNCkhpIGFsbCwNCg0KSSB0b29rIHRpbWUgdG8gc3R1ZHkgc29tZSBvZiB0aGUgZW1h aWwgZGlzY3Vzc2lvbiAoYWxiZWl0IG5vdCBhbGwpLiBJIG1hZGUgc3VyZSB0byBjYXJlZnVsbHkg cmVhZCB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IHdyaXR0ZW4gYnkgVG9tbXk6IGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWRkL3lGT3NkVE9mNlZmTnpzSFBVYnVGZlE1 VVJ6dy4NCg0KQXMgc2VjdXJpdHkgZm9sa3MsIG1hbnkgb2YgdXMgaW5hZHZlcnRlbnRseSBzb2x2 ZSBvdXIgcHJvYmxlbXMgYnkgbWFraW5nIHRoZW0gc29tZW9uZSBlbHNlJ3MuIEEgdmVyeSBuYWl2 ZSBleGFtcGxlIG9mIHRoaXMgd291bGQgYmUgdGhhdCB3ZSBzb2x2ZWQgdGhlIGtleSBleGNoYW5n ZSBwcm9ibGVtIG9mIHN5bW1ldHJpYyBrZXlzIGJ5IG1ha2luZyBpdCBhIGtleSBkaXN0cmlidXRp b24gcHJvYmxlbSB3aXRoIHB1YmxpYy1rZXkgY3J5cHRvZ3JhcGh5LiBJIGtub3cgdGhhdCB3ZSBz aG91bGRuJ3QgcmVhbGx5IGRpc2N1c3Mgc29sdXRpb25zIHdoZW4gZm9ybXVsYXRpbmcgdGhlIGNo YXJ0ZXIuIEhvd2V2ZXIsIEkgc3VnZ2VzdCB0aGF0IHdlIHVzZSB0aGlzIG9wcG9ydHVuaXR5IHRv IGRpc2N1c3MgdGhlIHN0YXJ0aW5nIGFzc3VtcHRpb25zIGZvciBhIGNsaWVudCB0byBzZWN1cmVs eSBkaXNjb3ZlciBETlMgcmVzb2x2ZXJzLg0KDQpTb21lIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlv bnMgdGhhdCBJIGxvb2tlZCBhdCByZWx5IG9uIGFuIGFub3RoZXIgdHJ1c3RlZCBzZXJ2ZXIgaW4g dGhlIG5ldHdvcmsgdG8gcHJvdmlkZSBpbmZvcm1hdGlvbiBhYm91dCBETlMgcmVzb2x2ZXJzLiBB bmQgaG93IGRvIEkgZGlzY292ZXIgdGhhdCB0cnVzdGVkIHNlcnZlcj8sIHdlbGwgb2YtY291cnNl LCBtRE5TLiBJIHdvdWxkIGxpa2UgdXMgdG8gc29sdmUgcmVhbCBwcm9ibGVtcyBhbmQgbm90IG1h a2UgY3ljbGljYWwgZGVwZW5kZW5jaWVzIChrbm93aW5nIHRoYXQgc29sdmluZyByZWFsIHByb2Js ZW1zIGlzIGhhcmQgYW5kIHRpbWUtY29uc3VtaW5nKS4gSSB3b3VsZCBhbHNvIGxpa2UgdG8gdW5k ZXJzdGFuZCB3aGF0IHR5cGUgb2YgbmV0d29ya3MgYXJlIGluIHNjb3BlPyBBc3N1bWluZyBhIHRy dXN0ZWQgc2VydmVyIGluIHRoZSBsb2NhbCBuZXR3b3JrIHRvIGluZm9ybSBtZSBhYm91dCBjYW5k aWRhdGUgRE5TIHJlc29sdmVycyBpcyBjZXJ0YWlubHkgbm90IGxpa2VseSBpbiBtYW55L21vc3Qg aG9tZSBuZXR3b3Jrcz8NCg0KLS1Nb2hpdA0KDQpPbiAxLzE4LzIwIDQ6MjAgQU0sIFJvYiBTYXly ZSB3cm90ZToNCk9uIEZyaSwgSmFuIDE3LCAyMDIwIGF0IDc6MjggQU0gUGF1bCBIb2ZmbWFuIDxw YXVsLmhvZmZtYW5AaWNhbm4ub3JnPG1haWx0bzpwYXVsLmhvZmZtYW5AaWNhbm4ub3JnPj4gd3Jv dGU6DQoNClRoaXMgcHJvcG9zYWwgcnVsZXMgb3V0IGFueSBzb2x1dGlvbiB0aGF0IGRvZXMgbm90 IG1hbmRhdGUgdGhlIGNsaWVudCAoc3VjaCBhcyBhbiBvcGVyYXRpbmcgc3lzdGVtKSBoYXZpbmcg YW4gdXAtdG8tZGF0ZSBzZXQgb2YgY3J5cHRvZ3JhcGhpYyB0cnVzdCBhbmNob3JzIChzdWNoIGFz IHRoZSB3ZWIgUEtJIG9yIG90aGVyIGNyeXB0byBpbml0aWFsaXphdGlvbiBieSB2ZW5kb3JzKS4g SXQgd291bGQgaG9iYmxlIGRpc2NvdmVyeSBpbiBtYW55IG9mIHRoZSBjb21tb24gY2FzZXMgdGhh dCBoYXZlIGJlZW4gZGlzY3Vzc2VkLCBzdWNoIGFzIG15IGxhcHRvcCBpbiBteSBob21lIHVzaW5n IG15IElTUCdzIHJlc29sdmVyLiBJZiB0aGF0IHR5cGUgb2YgaG9iYmxpbmcgaXMgd2hhdCB0aGlz IGdyb3VwIHdhbnRzLCBnbyBmb3IgaXQuLi4NCg0KV2hhdCBpcyB0aGUgaW1wcm92ZW1lbnQgc3Vj aCBhIGdyb3VwIHdvdWxkIG1pc3Mgb3V0IG9uPw0KDQp0aGFua3MsDQpSb2INCg0KDQoNCg0K --_000_03037960e9a73dd570093c79e589fd08ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <49E434E0F225874F852F43751A32FDFC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+TXkgY29tbWVu dCBtYXliZSBzb21ld2hhdCBtaXNsZWFkaW5nIGFuZCBtaWdodCBiZSBpbnRlcnByZXRlZCBhcyBp ZiBJIGFtIGFnYWluc3QgZm9ybWluZyB0aGlzIHdvcmtpbmcgZ3JvdXAuIFRoYXQgaXMgY2VydGFp bmx5IG5vdCB0aGUgY2FzZS4gSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHdvcmtpbmcgZ3JvdXAg Zm9ybWVkIGFuZCB3b3VsZCBiZSBoYXBweSB0byByZXZpZXcvY29udHJpYnV0ZSBhcyB3ZSBwcm9j ZWVkLg0KPGJyPg0KPC9wPg0KPHA+QXMgYSBtb3JlIGNvbmNyZXRlIHN1Z2dlc3Rpb24sIHBlcmhh cHMgdGhlIGZvbGxvd2luZyBidWxsZXQgaW4gdGhlIGN1cnJlbnQgY2hhcnRlciB0ZXh0IGNvdWxk IGJlIGJldHRlciBleHBsYWluZWQ6PGJyPg0KPGJyPg0KPC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+LSBkZWZpbmUgYSBtZWNoYW5pc20gdGhhdCBh bGxvd3MgY2xpZW50cyB0byBkaXNjb3ZlciBETlMgcmVzb2x2ZXJzLA0KaW5jbHVkaW5nIGVuY3J5 cHRlZCBETlMgc2VydmVycywgdGhhdCBhcmUgYXZhaWxhYmxlIHRvIHRoZSBjbGllbnQNCmVpdGhl ciBvbiB0aGUgcHVibGljIEludGVybmV0IG9yIG9uIHByaXZhdGUgb3IgbG9jYWwgbmV0d29ya3M7 PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQpSYXRoZXIgdGhhbiBkaXN0aW5ndWlzaGluZyBiZXR3ZWVu IHByaXZhdGUvbG9jYWwgbmV0d29ya3MgdnMuIEludGVybmV0LCBpdCBjb3VsZCBkaXN0aW5ndWlz aCBob21lL2VudGVycHJpc2UgbmV0d29ya3Mgb3Igd2hldGhlciBpbmZyYXN0cnVjdHVyZSBpcyBh dmFpbGFibGUgdG8gYWlkIHRoZSBkaXNjb3Zlcnkgb3Igbm90LiBGb3IgZXhhbXBsZSwgc29tZSBl bnRlcnByaXNlIG5ldHdvcmtzIG1heSBoYXZlIHNlcnZlcnMgKHN1Y2ggYXMgYSBXaW5kb3dzDQog QWN0aXZlIERpcmVjdG9yeSBEb21haW4gU2VydmljZSkgdG8gaGVscCBhc3Npc3QgaW4gdGhlIGRp c2NvdmVyeSBvZiBETlMgcmVzb2x2ZXJzLiBUaGlzIHdvdWxkIG5vdCBiZSBwb3NzaWJsZSBpbiBt YW55IGhvbWUgbmV0d29ya3Mgb24gdGhlIG90aGVyIGhhbmQuDQo8YnI+DQo8cD48L3A+DQo8cD4t LU1vaGl0PGJyPg0KPC9wPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxLzIxLzIw IDM6MDkgUE0sIE1vaGl0IFNldGhpIE0gd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjaXRlPSJtaWQ6OWMyNjE2MzYtYTAzMC02MTE2LTA5OGQtYWM4OWIxMjI3YmFk QGVyaWNzc29uLmNvbSI+DQo8cD5IaSBhbGwsPGJyPg0KPC9wPg0KPHA+SSB0b29rIHRpbWUgdG8g c3R1ZHkgc29tZSBvZiB0aGUgZW1haWwgZGlzY3Vzc2lvbiAoYWxiZWl0IG5vdCBhbGwpLiBJIG1h ZGUgc3VyZSB0byBjYXJlZnVsbHkgcmVhZCB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IHdyaXR0 ZW4gYnkgVG9tbXk6DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWRkL3lGT3NkVE9mNlZmTnpzSFBVYnVGZlE1VVJ6 dyI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FkZC95Rk9zZFRPZjZW Zk56c0hQVWJ1RmZRNVVSenc8L2E+LiA8YnI+DQo8L3A+DQo8cD5BcyBzZWN1cml0eSBmb2xrcywg bWFueSBvZiB1cyBpbmFkdmVydGVudGx5IHNvbHZlIG91ciBwcm9ibGVtcyBieSBtYWtpbmcgdGhl bSBzb21lb25lIGVsc2Uncy4gQSB2ZXJ5IG5haXZlIGV4YW1wbGUgb2YgdGhpcyB3b3VsZCBiZSB0 aGF0IHdlIHNvbHZlZCB0aGUga2V5IGV4Y2hhbmdlIHByb2JsZW0gb2Ygc3ltbWV0cmljIGtleXMg YnkgbWFraW5nIGl0IGEga2V5IGRpc3RyaWJ1dGlvbiBwcm9ibGVtIHdpdGggcHVibGljLWtleSBj cnlwdG9ncmFwaHkuDQogSSBrbm93IHRoYXQgd2Ugc2hvdWxkbid0IHJlYWxseSBkaXNjdXNzIHNv bHV0aW9ucyB3aGVuIGZvcm11bGF0aW5nIHRoZSBjaGFydGVyLiBIb3dldmVyLCBJIHN1Z2dlc3Qg dGhhdCB3ZSB1c2UgdGhpcyBvcHBvcnR1bml0eSB0byBkaXNjdXNzIHRoZSBzdGFydGluZyBhc3N1 bXB0aW9ucyBmb3IgYSBjbGllbnQgdG8gc2VjdXJlbHkgZGlzY292ZXIgRE5TIHJlc29sdmVycy4N Cjxicj4NCjwvcD4NCjxwPlNvbWUgb2YgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyB0aGF0IEkgbG9v a2VkIGF0IHJlbHkgb24gYW4gYW5vdGhlciB0cnVzdGVkIHNlcnZlciBpbiB0aGUgbmV0d29yayB0 byBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IEROUyByZXNvbHZlcnMuIEFuZCBob3cgZG8gSSBk aXNjb3ZlciB0aGF0IHRydXN0ZWQgc2VydmVyPywgd2VsbCBvZi1jb3Vyc2UsIG1ETlMuIEkgd291 bGQgbGlrZSB1cyB0byBzb2x2ZSByZWFsIHByb2JsZW1zIGFuZCBub3QNCiBtYWtlIGN5Y2xpY2Fs IGRlcGVuZGVuY2llcyAoa25vd2luZyB0aGF0IHNvbHZpbmcgcmVhbCBwcm9ibGVtcyBpcyBoYXJk IGFuZCB0aW1lLWNvbnN1bWluZykuIEkgd291bGQgYWxzbyBsaWtlIHRvIHVuZGVyc3RhbmQgd2hh dCB0eXBlIG9mIG5ldHdvcmtzIGFyZSBpbiBzY29wZT8gQXNzdW1pbmcgYSB0cnVzdGVkIHNlcnZl ciBpbiB0aGUgbG9jYWwgbmV0d29yayB0byBpbmZvcm0gbWUgYWJvdXQgY2FuZGlkYXRlIEROUyBy ZXNvbHZlcnMgaXMgY2VydGFpbmx5DQogbm90IGxpa2VseSBpbiBtYW55L21vc3QgaG9tZSBuZXR3 b3Jrcz88YnI+DQo8L3A+DQo8cD4tLU1vaGl0PGJyPg0KPC9wPg0KPGRpdiBjbGFzcz0ibW96LWNp dGUtcHJlZml4Ij5PbiAxLzE4LzIwIDQ6MjAgQU0sIFJvYiBTYXlyZSB3cm90ZTo8YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQUNocjZTeVVLbXZBUThuaVBZ alFtTDRFUkVZN2M2ZHFxc2pwLU0yYnQ0YV9pLUw0MEFAbWFpbC5nbWFpbC5jb20iPg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2IGRpcj0ibHRyIj5PbiBGcmksIEphbiAxNywgMjAyMCBhdCA3OjI4IEFN IFBhdWwgSG9mZm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWwuaG9mZm1hbkBpY2Fubi5vcmci IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cGF1bC5ob2ZmbWFuQGljYW5uLm9yZzwvYT4mZ3Q7IHdy b3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4DQogICAgICAgICAg ICAgIDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZA0KICAgICAgICAgICAgICByZ2IoMjA0LDIw NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KVGhpcyBwcm9wb3NhbCBydWxlcyBvdXQg YW55IHNvbHV0aW9uIHRoYXQgZG9lcyBub3QgbWFuZGF0ZSB0aGUgY2xpZW50IChzdWNoIGFzIGFu IG9wZXJhdGluZyBzeXN0ZW0pIGhhdmluZyBhbiB1cC10by1kYXRlIHNldCBvZiBjcnlwdG9ncmFw aGljIHRydXN0IGFuY2hvcnMgKHN1Y2ggYXMgdGhlIHdlYiBQS0kgb3Igb3RoZXIgY3J5cHRvIGlu aXRpYWxpemF0aW9uIGJ5IHZlbmRvcnMpLiBJdCB3b3VsZCBob2JibGUgZGlzY292ZXJ5IGluIG1h bnkgb2YNCiB0aGUgY29tbW9uIGNhc2VzIHRoYXQgaGF2ZSBiZWVuIGRpc2N1c3NlZCwgc3VjaCBh cyBteSBsYXB0b3AgaW4gbXkgaG9tZSB1c2luZyBteSBJU1AncyByZXNvbHZlci4gSWYgdGhhdCB0 eXBlIG9mIGhvYmJsaW5nIGlzIHdoYXQgdGhpcyBncm91cCB3YW50cywgZ28gZm9yIGl0Li4uPGJy Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hhdCBpcyB0aGUgaW1w cm92ZW1lbnQgc3VjaCBhIGdyb3VwIHdvdWxkIG1pc3Mgb3V0IG9uPzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+dGhhbmtzLDwvZGl2Pg0KPGRpdj5Sb2ImbmJzcDs8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48 L2ZpZWxkc2V0PiA8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRh Y2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PiA8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_03037960e9a73dd570093c79e589fd08ericssoncom_-- From nobody Wed Jan 22 06:23:41 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA831200E9 for ; Wed, 22 Jan 2020 06:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 dtSrW8d9Ns3b for ; Wed, 22 Jan 2020 06:23:37 -0800 (PST) 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 6DA141200F4 for ; Wed, 22 Jan 2020 06:23:37 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id z76so6533073qka.2 for ; Wed, 22 Jan 2020 06:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l7YLC5aYRwnQWsxMwky8xPuVSh+z0Llhmkovzzdxv7o=; b=iRF3wky+Wfb3+SoR4crS2Si7RVYOWFudxNBk5YMM17/X/q7nefpi5xtqubTjqzOrtn /rMWh4xkmOxU/A6o/VN+UKLw/lkOCrV3Pb+97pZEsGkZDkaGjKZV4d6L2yvvsGe+1jyW ksAzyxuuk5YxhLDxq70VpDhmKEi4ib8yZFWYlSitRCyB7RR6P7WjA0Km2m/ZHHtzjeuR 8qbWZVpKIYNY37Ve8YbGNHiCSFkcplQNZskHscXrNwfQuu/UsXOYqAq4U91/iJTFLchR 8GJkXxkPl6f1HZJv+XhDFlIgnsKnfGaMpD4+Xz2PZo9etUEGmNJPLFFF2wMWh9xVJf7i p0mg== 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=l7YLC5aYRwnQWsxMwky8xPuVSh+z0Llhmkovzzdxv7o=; b=p5YQ1AsvvMWwP22Y3QAmhOJdCcO5A50Hko9SnHEB3Jqfj1/3IaINeB+i4qbkiznuR1 eGGVZzRfcFxTQCyaqx6XWv09f82AlhMgL9voIj4AqjxByN4olztCxRIVOGQ3JTBcPCC3 2/MNest16Ib7FqNh2bjycFSWWt6hF5Q7R0gqihDG8mnQeTFRqheMEmgZClHoKybsbEn+ 0rUL93ZeVIitSYVmYXSLcDU9wOMxTvyapJl8vPRknk0nyAX0IAjLqAiPSUuI4APjsBTO EwJqifbGiMnAsEVoc7dD+99ZUr8+egyjnVi66FodsnyPo68O6bCOjuXQ6ZsvnkBbk6FD cJtw== X-Gm-Message-State: APjAAAUPKnT/VncLG8Rvs4kOi+HV6vVvPLOV6V41oULV27THEMb6jLrX hlLig4bwMRWYi6dppGL9uw+Onw== X-Google-Smtp-Source: APXvYqxE6U02b4CCNr3PvCI20Fjm8wyMLdVtNkhGwmSBeIRhMGgYyGg8NgfBbQF3vrBjbdzQWvVuVQ== X-Received: by 2002:ae9:df83:: with SMTP id t125mr10052149qkf.384.1579703016310; Wed, 22 Jan 2020 06:23:36 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:584f:8905:383c:90b7? ([2601:18b:300:36ee:584f:8905:383c:90b7]) by smtp.gmail.com with ESMTPSA id r5sm137640qta.36.2020.01.22.06.23.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 06:23:35 -0800 (PST) From: Ted Lemon Message-Id: <97C1A1AA-D146-4B07-8489-9658385F3DF1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_50B3FEA6-90FA-4989-896F-B973AE469A6E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 22 Jan 2020 09:23:34 -0500 In-Reply-To: <03037960-e9a7-3dd5-7009-3c79e589fd08@ericsson.com> Cc: "add@ietf.org" To: Mohit Sethi M References: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> <9c261636-a030-6116-098d-ac89b1227bad@ericsson.com> <03037960-e9a7-3dd5-7009-3c79e589fd08@ericsson.com> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Add] Food for thought? X-BeenThere: add@ietf.org X-Mailman-Version: 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, 22 Jan 2020 14:23:40 -0000 --Apple-Mail=_50B3FEA6-90FA-4989-896F-B973AE469A6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 22, 2020, at 8:50 AM, Mohit Sethi M = wrote: > Rather than distinguishing between private/local networks vs. = Internet, it could distinguish home/enterprise networks or whether = infrastructure is available to aid the discovery or not. For example, = some enterprise networks may have servers (such as a Windows Active = Directory Domain Service) to help assist in the discovery of DNS = resolvers. This would not be possible in many home networks on the other = hand.=20 Practically speaking, it might help to think of this in terms of = scenarios rather than types of networks. It=E2=80=99s true e.g. that a = corporate network may have WADDS, but it may also not. What matters is = whether it has it, not whether it is a corporate network. It might = help with clarity if we think about it this way, although I agree with = your basic point. And then what is it about WADDS that makes it able to help the client to = find a secure resolver, as compared to unauthenticated DHCP? Is it a = property that is unique to WADDS, or is WADDS implementing an example of = some property that other services might also be able to implement? --Apple-Mail=_50B3FEA6-90FA-4989-896F-B973AE469A6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 22, 2020, at 8:50 AM, Mohit Sethi M <mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> = wrote:
Rather than distinguishing = between private/local networks vs. Internet, it could distinguish = home/enterprise networks or whether infrastructure is available to aid = the discovery or not. For example, some enterprise networks may have = servers (such as a Windows Active Directory Domain Service) to help = assist in the discovery of DNS resolvers. This would not be possible in = many home networks on the other hand. 

Practically speaking, it might help to = think of this in terms of scenarios rather than types of networks. =   It=E2=80=99s true e.g. that a corporate network may have WADDS, = but it may also not.  What matters is whether it has it, not = whether it is a corporate network.   It might help with clarity if = we think about it this way, although I agree with your basic = point.

And = then what is it about WADDS that makes it able to help the client to = find a secure resolver, as compared to unauthenticated DHCP?   Is = it a property that is unique to WADDS, or is WADDS implementing an = example of some property that other services might also be able to = implement?

= --Apple-Mail=_50B3FEA6-90FA-4989-896F-B973AE469A6E-- From nobody Wed Jan 22 07:45:20 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AAB1200F5 for ; Wed, 22 Jan 2020 07:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 ZSMcN3Y7jRgg for ; Wed, 22 Jan 2020 07:45:14 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435CE1200F7 for ; Wed, 22 Jan 2020 07:45:14 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id c4so5479142ilo.7 for ; Wed, 22 Jan 2020 07:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EcXis8lPitLhHsM3lvnRVrJbqdnAydqT6vQbY3l7GnA=; b=rtkKw7Xmth1ZiJIP1v/eJgdRY+MMHn5Db3uuek1BF+uO232TLbm9fTfpK4USLYhA2p 8RV31TDozdd/puOQsP+Nb23XMzMsgOLJLtmCnFtBsy+ClDgVEJLSh7L2lFDWfRgneSVs wNmUyBlkTXGWkTtqlhJXkEUxgvTSVQQYEvU66TrK5bQtGRTe4girG+EbVHAYXNLupW4V c+kVQl0BWHz22s9UMfC5effeKCr3qoXz6jo7CO7psUEyO9u5N70Z2HS1tjD3fTlYg31Y mPAThz0Y6Xwjwdt8AVON650jh4RTEm3A+kk+LGLiWIGTOZLhLWH8EOIzuq+inyk0anER Obsw== 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=EcXis8lPitLhHsM3lvnRVrJbqdnAydqT6vQbY3l7GnA=; b=UJdMzNZH2lRrBQxz0zXPEFc6QxkvNkK5GI6rRk6YxcfrP32Xezu2NE0j2XGXLv0Dwr RPyZCCkIvmwvqMSxLJ9ogNaz3OVU/D5AhVqFoirKBOZAwboiSDJlI+z49BNgM5kpVntG 6ucybYEHCLNSyiWuLvm3yAtMzHLA0K4XBZdng2v0+3/7v7SkVg2RuUDFzvSDE4kqKfR7 B+5+oDQeaV5e1ggd0fKle8F2muhqY2k4VtSysonFgOpguaHfixaesRK3HdADVYunpRTx PCdUbg1Ps3wFqhVM1xCLQVm4zIkaN7NqCTukc9gHZPhJm9HZN4UpIfqltFONkZ5Cly9L L8Zg== X-Gm-Message-State: APjAAAUEI5TGNhhqTZKal54Q4Y1cTyVd9PhmPU3yaL37YodMdnNmHWGu 4FyouKafCP2w3zt+ijJtfYoxcO4LvEAgnVoZFo4= X-Google-Smtp-Source: APXvYqxTW/Nwew9eJuKwgf7admFFPqFe71LWxGVeFzW0JPrLL24+n5AuzTyx3TpIhVb6YzhOHDaRA67DyimZlwNXseo= X-Received: by 2002:a05:6e02:f0f:: with SMTP id x15mr8386228ilj.298.1579707913557; Wed, 22 Jan 2020 07:45:13 -0800 (PST) MIME-Version: 1.0 References: <7B424818-0F38-44E7-8EDE-165E96A6221A@icann.org> <9c261636-a030-6116-098d-ac89b1227bad@ericsson.com> <03037960-e9a7-3dd5-7009-3c79e589fd08@ericsson.com> <97C1A1AA-D146-4B07-8489-9658385F3DF1@fugue.com> In-Reply-To: <97C1A1AA-D146-4B07-8489-9658385F3DF1@fugue.com> From: tirumal reddy Date: Wed, 22 Jan 2020 21:15:01 +0530 Message-ID: To: Ted Lemon Cc: Mohit Sethi M , "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000095ab8059cbc69e3" Archived-At: Subject: Re: [Add] Food for thought? X-BeenThere: add@ietf.org X-Mailman-Version: 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, 22 Jan 2020 15:45:17 -0000 --000000000000095ab8059cbc69e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 22 Jan 2020 at 19:53, Ted Lemon wrote: > On Jan 22, 2020, at 8:50 AM, Mohit Sethi M < > mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> wrote: > > Rather than distinguishing between private/local networks vs. Internet, i= t > could distinguish home/enterprise networks or whether infrastructure is > available to aid the discovery or not. For example, some enterprise > networks may have servers (such as a Windows Active Directory Domain > Service) to help assist in the discovery of DNS resolvers. This would not > be possible in many home networks on the other hand. > > > Practically speaking, it might help to think of this in terms of scenario= s > rather than types of networks. It=E2=80=99s true e.g. that a corporate = network > may have WADDS, but it may also not. What matters is whether it has it, > not whether it is a corporate network. It might help with clarity if we > think about it this way, although I agree with your basic point. > > And then what is it about WADDS that makes it able to help the client to > find a secure resolver, as compared to unauthenticated DHCP? > Policies can be configured on both the OS and browsers in the endpoint via Active directory, Discovery of DoH/DoT servers is not required. For instance, see https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy= -windows, the policy can specify the Enterprise DoT/DoH server the browser should use= . The challenge is with BYOD devices or Enterprise networks that have limited/no configuration control on endpoints. Cheers, -Tiru > Is it a property that is unique to WADDS, or is WADDS implementing an > example of some property that other services might also be able to > implement? > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000095ab8059cbc69e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 22 Jan 2020 at 19:53, Ted Lemon &= lt;mellon@fugue.com> wrote:
<= /div>
On Jan 22, 2020, at 8:50 A= M, Mohit Sethi M <mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org<= /a>> wrote:
Rather than distinguishing between private/local net= works vs. Internet, it could distinguish home/enterprise networks or whethe= r infrastructure is available to aid the discovery or not. For example, som= e enterprise networks may have servers (such as a Windows Active Directory = Domain Service) to help assist in the discovery of DNS resolvers. This woul= d not be possible in many home networks on the other hand.=C2=A0

Practically speaking, it might h= elp to think of this in terms of scenarios rather than types of networks. = =C2=A0 It=E2=80=99s true e.g. that a corporate network may have WADDS, but = it may also not.=C2=A0 What matters is whether it has it, not whether it is= a corporate network. =C2=A0 It might help with clarity if we think about i= t this way, although I agree with your basic point.

And then what is it about WADDS that makes it able to help the client to = find a secure resolver, as compared to unauthenticated DHCP? =C2=A0
<= /div>


The challenge is with BYOD devices or = Enterprise networks that have limited/no configuration control on endpoints= .=C2=A0

Cheers,
-Tiru
=C2= =A0
Is it a property that is unique to WADDS, or= is WADDS implementing an example of some property that other services migh= t also be able to implement?

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000095ab8059cbc69e3-- From nobody Wed Jan 22 08:12:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D3E12010E for ; Wed, 22 Jan 2020 08:12:41 -0800 (PST) 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 xwtPtYB0NDP5 for ; Wed, 22 Jan 2020 08:12:39 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39EF4120089 for ; Wed, 22 Jan 2020 08:12:39 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id j20so187239qka.10 for ; Wed, 22 Jan 2020 08:12:39 -0800 (PST) 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=Guo8U2yW+leNBpZYGcEcxqz+ijhChvlcCNtoxc+/Xrs=; b=JZgzWbgavTCS9oB9HHjxNEVaQ1FuyCsfvkoEMMi23xAXKQmblOARzCqciQwTUJ+2yY pfFQ2JQvb+mp5M6h+wK1gJyqomCy9VHGfTitpVJ64tyZy6lld8lyDuPfq+puDj5tci8W bLk9XlEbgHtPoPHEHzEQSssdn5s8/thIGvZBwooDsvO+1H/LzmOPuGbK2iRN9wpIDZ73 iEIYphV2dnRnJOcz/JwyKcI94TBhQuR1ykPtVBmc20ZeXh3txEDJ7cueb+8G+OXeb3dY 5ADVaEPHTBBOBcoR2IAsYTf88LZJmPqU2Rq5MeoNvqrdg8N/A7sLIxRkAi2JL6T7LKuj uQ8w== 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=Guo8U2yW+leNBpZYGcEcxqz+ijhChvlcCNtoxc+/Xrs=; b=nwIWZNSFS9p1wTCpvR6RjozCty0jaiATB/BqZJA5d7PJlNwJp6zE+t8osLm0Zsndgn xm/BEhIifJFG+/V780RqQq2NCUNpVahHIFVwCDMzq4XwRkW+w8R8kF2UmaC5VOXf4HhV 4bO6Y6dU73QLwZOQbrUGchuiQUEpumxhfImu/htw733DjwPpS6EG0nl3porj2lr3WGPe yMGKZcBytMFXkXR9Tow6NFtHBpP/8IGHM2qP1keVwcPqMwZzr/dSbAjtDfsSi3yCgFPZ jqxGV0JGoxyQ8GdX0lfCrl9h4L9v/Dfm+AjiqF+9udO5A7qFxceYL3In8MvjLXJQUBRI RzlA== X-Gm-Message-State: APjAAAWUh79Ul+SQf2YfpvQJEx07mjXS24+mggxciOViEuAKi+2VJDaF bXNYM9/mnHD0GaXv9cHOyw/oaA== X-Google-Smtp-Source: APXvYqzCkLk0HKOcBQkgoZjRrD+e8HErULbc8dNVIEX3Smk+T1bFHRDl4xEnU2ttFB2YYXeqsoF3Vg== X-Received: by 2002:a05:620a:62c:: with SMTP id 12mr10816250qkv.154.1579709558372; Wed, 22 Jan 2020 08:12:38 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e8e9:2624:8291:2383? ([2601:18b:300:36ee:e8e9:2624:8291:2383]) by smtp.gmail.com with ESMTPSA id 17sm19234317qkl.106.2020.01.22.08.12.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jan 2020 08:12:37 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-9C4DA4D9-455B-477C-B1E6-EBC13DFAAEA4 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 22 Jan 2020 11:12:37 -0500 Message-Id: <1A745C22-3815-454B-8A0E-5A40D27A071C@fugue.com> References: Cc: Mohit Sethi M , "add@ietf.org" In-Reply-To: To: tirumal reddy X-Mailer: iPhone Mail (17E210a) Archived-At: Subject: Re: [Add] Food for thought? X-BeenThere: add@ietf.org X-Mailman-Version: 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, 22 Jan 2020 16:12:41 -0000 --Apple-Mail-9C4DA4D9-455B-477C-B1E6-EBC13DFAAEA4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So you=E2=80=99re proposing this as a way to configure a verifiable trust re= lationship, right? In this case, the trust relationship is with the active d= irectory server and is set up by the system administrator? For the case of BYOD, such devices should not be permitted access to the int= ernal network. This is standard operating procedure at many enterprise sites= already, and it=E2=80=99s just common sense. I think most devices you can g= et can already be set up this way, for example with a provisioning profile o= n iOS.=20 > On Jan 22, 2020, at 10:45, tirumal reddy wrote: >=20 > =EF=BB=BF >> On Wed, 22 Jan 2020 at 19:53, Ted Lemon wrote: >=20 >>> On Jan 22, 2020, at 8:50 AM, Mohit Sethi M wrote: >>> Rather than distinguishing between private/local networks vs. Internet, i= t could distinguish home/enterprise networks or whether infrastructure is av= ailable to aid the discovery or not. For example, some enterprise networks m= ay have servers (such as a Windows Active Directory Domain Service) to help a= ssist in the discovery of DNS resolvers. This would not be possible in many h= ome networks on the other hand.=20 >>=20 >> Practically speaking, it might help to think of this in terms of scenario= s rather than types of networks. It=E2=80=99s true e.g. that a corporate n= etwork may have WADDS, but it may also not. What matters is whether it has i= t, not whether it is a corporate network. It might help with clarity if we= think about it this way, although I agree with your basic point. >>=20 >> And then what is it about WADDS that makes it able to help the client to f= ind a secure resolver, as compared to unauthenticated DHCP? =20 >=20 > Policies can be configured on both the OS and browsers in the endpoint via= Active directory, Discovery of DoH/DoT servers is not required. For instanc= e, see https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-= policy-windows, the policy can specify the Enterprise DoT/DoH server the bro= wser should use. >=20 > The challenge is with BYOD devices or Enterprise networks that have limite= d/no configuration control on endpoints.=20 >=20 > Cheers, > -Tiru > =20 >> Is it a property that is unique to WADDS, or is WADDS implementing an exa= mple of some property that other services might also be able to implement? >>=20 >> --=20 >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add --Apple-Mail-9C4DA4D9-455B-477C-B1E6-EBC13DFAAEA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
So you=E2=80=99re proposin= g this as a way to configure a verifiable trust relationship, right?  I= n this case, the trust relationship is with the active directory server and i= s set up by the system administrator?

For the case of BYOD, such devices should not be permitted access= to the internal network. This is standard operating procedure at many enter= prise sites already, and it=E2=80=99s just common sense. I think most device= s you can get can already be set up this way, for example with a provisionin= g profile on iOS. 

= On Jan 22, 2020, at 10:45, tirumal reddy <kondtir@gmail.com> wrote:
=EF=BB=BF=
On Wed, 22 Jan 2020 at 19:53, Ted Lemon &l= t;mellon@fugue.com> wrote:
On Jan 22, 2020, at 8:50 AM, Mo= hit Sethi M <mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org>= wrote:
Rather than distinguishing between private/local networks vs. In= ternet, it could distinguish home/enterprise networks or whether infrastruct= ure is available to aid the discovery or not. For example, some enterprise n= etworks may have servers (such as a Windows Active Directory Domain Service)= to help assist in the discovery of DNS resolvers. This would not be possibl= e in many home networks on the other hand. 

Practically speaking, it might help to think of th= is in terms of scenarios rather than types of networks.   It=E2=80=99s t= rue e.g. that a corporate network may have WADDS, but it may also not. = What matters is whether it has it, not whether it is a corporate network. &= nbsp; It might help with clarity if we think about it this way, although I a= gree with your basic point.

And then what is it abo= ut WADDS that makes it able to help the client to find a secure resolver, as= compared to unauthenticated DHCP?  

=
Policies can be configured on both the OS and browsers in the end= point via Active directory, Discovery of DoH/DoT servers is not required. Fo= r instance, see https://support.mozilla.org/en-US/k= b/customizing-firefox-using-group-policy-windows, the policy can specify= the Enterprise DoT/DoH server the browser should use.

<= div>The challenge is with BYOD devices or Enterprise networks that have limi= ted/no configuration control on endpoints. 

Ch= eers,
-Tiru
 
Is it a p= roperty that is unique to WADDS, or is WADDS implementing an example of some= property that other services might also be able to implement?
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
= --Apple-Mail-9C4DA4D9-455B-477C-B1E6-EBC13DFAAEA4-- From nobody Tue Jan 28 07:38:15 2020 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 8B7D8120993; Tue, 28 Jan 2020 07:38:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158022588956.4533.3226994933448699836.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 07:38:09 -0800 From: IETF Secretariat Archived-At: Subject: [Add] Datatracker State Update Notice: 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: Tue, 28 Jan 2020 15:38:10 -0000 State changed to Start Chartering/Rechartering (Internal IESG/IAB Review). Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-add/ From nobody Tue Jan 28 07:40:54 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8921209D1 for ; Tue, 28 Jan 2020 07:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, 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 uxSXvmgTY5no for ; Tue, 28 Jan 2020 07:40:50 -0800 (PST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (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 10F601208EA for ; Tue, 28 Jan 2020 07:40:50 -0800 (PST) Received: by mail-io1-f42.google.com with SMTP id h8so14730272iob.2 for ; Tue, 28 Jan 2020 07:40:50 -0800 (PST) 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=Ux3ew2sj2eNaNQK2TfdXuvUSwvHy1rHWa67I7Z1qINk=; b=Vl0A5nK3UnkYlfzrBc/mBMLm+E+ZQsFZW+yFO3PyObLjXl8qmw+Ix7I1zFjnT7LDcO nrs0JAWsS955kHI4ywG0pRSvMvIkuhRJ2e5/ivrUV876uluL0tOI51WBQUmuVBjMmCI+ CaQMBqrJWWht/fRhmLsmGvP5iY/LBjJb6x9JG+3CZCNDq1KvmjqovvXNKHJfYqw4O07q BMnDZQ8KMxoqwMnCWPLWuaX0IjcNTnqWWQnlGNuLjcMJtZy0EMM03+Ann7G1vtrwRiCl nA3OKF7E/1u7JJgP4yM6S3OO9XL6JDq27hm6fN28wovVhSxVKgqZdh1gN1Uv9+epebjc ou8g== X-Gm-Message-State: APjAAAXnXiL98wqYpK6NVjGjAs8s3jOuePB6UDI3L3k+z1+hKt7Uw6za SZBDFGWWYO/nkL5dSdlKENhGlUIuk7H9ExtqDFs= X-Google-Smtp-Source: APXvYqx8o0n1ol/EqjzP5onIKAC65uV36KY0tryLZUE/9DftDKjC7zV+d/6YAFgtivooyM7swfEekICGrrvvNnFMEQU= X-Received: by 2002:a5d:9b94:: with SMTP id r20mr17229990iom.140.1580226049057; Tue, 28 Jan 2020 07:40:49 -0800 (PST) MIME-Version: 1.0 References: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> In-Reply-To: <00CA3C8F-C471-4F4D-88BC-7D42265F5A03@apple.com> From: Barry Leiba Date: Tue, 28 Jan 2020 07:40:38 -0800 Message-ID: To: Tommy Pauly Cc: ADD Mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Charter proposal for ADD X-BeenThere: add@ietf.org X-Mailman-Version: 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, 28 Jan 2020 15:40:54 -0000 I have begun the chartering process with the charter below, modulo a small edit by me in the last paragraph. https://datatracker.ietf.org/doc/charter-ietf-add/ It would be good if we could have an estimated milestone based on the assumption that this working group would be chartered by and meet at IETF 107 in Vancouver. Barry, ART AD On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly wrote: > > Hi ADD, > > As our discussion on the proposed charter has quieted down, I wanted to s= end a brief update and summary. > > The main point of discussion was the paragraph on security requirements t= hat began "Any mechanisms that...". As many people stated on the previous t= hread, the necessity for security considerations and security area review i= n work produced by an IETF working group is already well-established, so th= is text is not needed specifically in this charter. There were some proposa= ls to tweak the language, but on the whole, it seems that we can live witho= ut that paragraph. > > Jari also had a good suggestion to include a sentence about the impact of= resolver selection (on reachability and privacy, etc). After looking at ad= ding that text, I am concerned that adding it to the charter gets into too = many details that really belong in the WG documents, particularly around ho= w to assess the "privacy" implications of choosing one resolver over anothe= r. The charter does indicate that these mechanisms are being used to "provi= de benefits to the security and privacy of DNS data", and it does cover rea= chability with the example of "a resolver may be able to resolve private or= local names...". As such, I'd prefer to not add any new sentence for now (= and Jari indicated he could live with the text as is!). > > I've included the updated proposal, which matches the previous proposal a= nd removes the text on security requirements. Based on the previous thread,= this should represent the consensus of the list. > > Barry, can you help get this started in the process of chartering? > > Best, > Tommy > > > > Adaptive DNS Discovery (ADD) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Proposed Working Group Charter > > Sending DNS messages over encrypted transports, as defined in DNS over > TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides > benefits to the security and privacy of DNS data. Clients, such as > applications and host operating systems, have started adopting these > protocols to provide these user benefits. > > This working group will focus on discovery and selection of DNS resolvers > by DNS clients in a variety of networking environments, including public > networks, private networks, and VPNs; supporting both encrypted and > unencrypted resolvers. > > Clients adopting encrypted DNS protocols need to determine which DNS > servers support encrypted transports, and which server to use for specifi= c > queries if multiple servers are available. These decisions can vary based > on the network environment, and also based on the content and purpose of > the client queries. > > Network operators that start offering DNS encryption on their servers als= o > need a way to indicate this support to clients. Communicating information > about resolver configuration and behavior allows clients to make more > informed decisions about which DNS servers to use. For example, a resolve= r > may be able to resolve private or local names as a split DNS server. > > The Adaptive DNS Discovery (ADD) working group will work on the following > deliverables: > > - define a mechanism that allows clients to discover DNS resolvers, > including encrypted DNS servers, that are available to the client > either on the public Internet or on private or local networks; > > - define a mechanism that allows communication of DNS resolver > information to clients for use in selection decisions; > > - develop an informational document that describes how client > applications and systems can manage selection of DNS resolvers > in various network environments and use cases. > > This working group will coordinate with dnsop, doh, and dprive for any > changes required in DNS protocols. It will also work with capport to > ensure that solutions are applicable to captive networks. > From nobody Tue Jan 28 08:16:13 2020 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 A5254120869; Tue, 28 Jan 2020 08:16:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: add@ietf.org, add-chairs@ietf.org, add@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158022816463.4660.7435168669343298644.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 08:16:04 -0800 Archived-At: Subject: [Add] Warren Kumari's Yes on charter-ietf-add-00-00: (with COMMENT) 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: Tue, 28 Jan 2020 16:16:05 -0000 Warren Kumari has entered the following ballot position for charter-ietf-add-00-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-add/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do not believe that this charter is perfect (nor that there won't be drama!), but I think that it's more than good enough to get the WG chartered, and start discussing documents... From nobody Tue Jan 28 09:40:15 2020 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 6E7D0120024; Tue, 28 Jan 2020 09:40:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "The IESG" , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158023320939.4537.8270693772931661337.idtracker@ietfa.amsl.com> Date: Tue, 28 Jan 2020 09:40:09 -0800 From: IETF Secretariat Archived-At: Subject: [Add] Telechat update notice: 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: Tue, 28 Jan 2020 17:40:10 -0000 Placed on agenda for telechat - 2020-02-06 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-add/