IETF Logo Mail Archive

Re: [Add] [Ext] Updated charter proposal for ADD

Paul Hoffman <paul.hoffman@icann.org> Fri, 17 January 2020 15:28 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: add@ietfa.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 <add@ietfa.amsl.com>; 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 <add@ietfa.amsl.com>; 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 <add@ietf.org>; 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 <add@ietf.org>; 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 <paul.hoffman@icann.org>
To: ADD Mailing list <add@ietf.org>
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: <CAChr6SwZMid9ruggYAu5bqBEcujhczp34mJ=TZPAjSXw50ZBKQ@mail.gmail.com> <C70ECC76-7431-4FC2-B555-0E1D8D82B449@nbcuni.com> <CAChr6SwYtJh84CLE9n+fuqjdFAaSzNP=aFKqa70KY=Mx+F76MQ@mail.gmail.com> <CWXP265MB0566FDF1030771C6916BE37AC2360@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM> <F82221F8-35B8-497F-8AA9-F2405000650F@fugue.com> <CAOdDvNqyJhu_q8ALpBeg=zcjyUpHW=fpTxSsoCV0_c=oiXg=pA@mail.gmail.com>
In-Reply-To: <CAOdDvNqyJhu_q8ALpBeg=zcjyUpHW=fpTxSsoCV0_c=oiXg=pA@mail.gmail.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=_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: <https://mailarchive.ietf.org/arch/msg/add/wSSyI867unqrH6VnkhnaRXEXbtw>
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 <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 15:28:42 -0000

On Jan 17, 2020, at 7:16 AM, Patrick McManus <mcmanus@ducksong.com> 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.
> 
> 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.

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

v2.23.0 | Report a Bug | By Email