From nobody Mon Apr 1 02:59:08 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9AF120147; Mon, 1 Apr 2019 02:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYgbKwq6sDYy; Mon, 1 Apr 2019 02:58:55 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 CD0D91200FD; Mon, 1 Apr 2019 02:58:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,296,1549926000"; d="scan'208,217";a="301368646" Received: from wifi-pro-83-211.paris.inria.fr ([128.93.83.211]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2019 11:58:52 +0200 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <5BFE7704-2EF0-4F53-9299-299FEC3687D3@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 1 Apr 2019 11:58:52 +0200 In-Reply-To: <1912967484.2862085.1553967089097.JavaMail.zimbra@inria.fr> Cc: secdispatch@ietf.org, 6tisch <6tisch@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org> To: Thomas Watteyne References: <1912967484.2862085.1553967089097.JavaMail.zimbra@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 09:59:07 -0000 --Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 We are happy to contribute to this effort through feedback on the = design, implementation for constrained devices and its evaluation in = 6TiSCH networks. Mali=C5=A1a > On 30 Mar 2019, at 18:31, Thomas Watteyne = wrote: >=20 > The 6TiSCH WG has produced a set of documents [1,2] that specify the = use of OSCORE to secure message exchanges at the application layer = including network access. At the side meeting in Prague two years ago = involving several ADs and WG chairs, the 6TiSCH chairs have indicated = the need for an efficient authenticated key exchange protocol that we = could use during the network access to key OSCORE. We have also restated = this request at the SECDISPATCH interim a couple of weeks ago. >=20 > The EDHOC specification was discussed on numerous occasions during the = 6TiSCH working group meetings and the approach on using it for the = extension of [1] towards zero-touch [3] deployments had a wide = consensus. We welcome the work in this area to be done, and strongly = support any decision of the security ADs that leads to the fast progress = of this specification. >=20 > [1] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ = =20= > [2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ = > [3] = https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-jo= in/ = =20 >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch --Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

We are = happy to contribute to this effort through feedback on the design, = implementation for constrained devices and its evaluation in 6TiSCH = networks.

Mali=C5=A1a

On 30 Mar 2019, at 18:31, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:

The 6TiSCH WG has produced a = set of documents [1,2] that specify the use of OSCORE to secure message = exchanges at the application layer including network access. At the side = meeting in Prague two years ago involving several ADs and WG chairs, the = 6TiSCH chairs have indicated the need for an efficient authenticated key = exchange protocol that we could use during the network access to key = OSCORE. We have also restated this request at the SECDISPATCH interim a = couple of weeks ago.

The EDHOC specification was discussed = on numerous occasions during the 6TiSCH working group meetings and the = approach on using it for the extension of [1] towards zero-touch [3] = deployments had a wide consensus. We welcome the work in this area to be = done, and strongly support any decision of the security ADs that leads = to the fast progress of this specification.

[1] https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-secur= ity/ 
[2] https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/=
[3] https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-ze= rotouch-join/ 

_______________________________________= ________
Secdispatch mailing list
Secdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/secdispatch

= --Apple-Mail=_BDB4EBED-1035-4578-9DBE-87F16AC0E864-- From nobody Mon Apr 1 05:06:11 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27412010C; Mon, 1 Apr 2019 05:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DF+D3qsL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e5HGa06n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMMU_q7pOjJQ; Mon, 1 Apr 2019 05:06:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9171C120100; Mon, 1 Apr 2019 05:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15678; q=dns/txt; s=iport; t=1554120365; x=1555329965; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N2LaIsPQDZ8wzpRUHGwFNcw5rU+M7rV0ufAzarxZx+4=; b=DF+D3qsLw5YKFJOviy9F8KI6Ef4ZtvYoCOoV7VgxvQxTXKFArj0iePrY UwGsiWGrXwP4VEomxNpmPeKnAk4iOtVU8uxyVjyyKzsIXMbOgP18rtm9i aDANrjulA4ooJaHjCLq0lZBNNZoAyFtpm3qyDKyiagNOsAEb4yfHxMGcd Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Ame0dwRDA/GyjNjhOcZhzUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACS/aFc/5BdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vUANodAQLJwqEBINHA4RSimCCV5J?= =?us-ascii?q?GhEmBLoEkA1QOAQEYAQwHg3pGAheFLCI0CQ0BAQMBAQkBAwJtHAyFSgEBAQE?= =?us-ascii?q?DAQEhChMBASwLAQ8CAQgRAQMBASgDAgICJQsUAwYIAgQBDQUIgxuBEUwDFQE?= =?us-ascii?q?CDJ8SAooUcYEvgnkBAQWBMQEDAw1BgnMYggwDBYEvAYsyF4FAP4FXgkw+gmE?= =?us-ascii?q?BAQIBARaBSSsJglQxgiaNA4QjlCcJAodvjAmQLoN+iz+GEY09AgQCBAUCDgE?= =?us-ascii?q?BBYFNODWBIXAVO4I4AQEyggqDboUUhT9yDIEcjhQBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,296,1549929600"; d="scan'208,217";a="255796310" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2019 12:06:04 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x31C64cL026714 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Apr 2019 12:06:04 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 07:06:03 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 07:06:03 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 1 Apr 2019 07:06:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N2LaIsPQDZ8wzpRUHGwFNcw5rU+M7rV0ufAzarxZx+4=; b=e5HGa06nIcPqiK1pxKSjEQ76D4Pjd1f6S9shOHTB/wf8XdRgtA271Ajmo6CDy2dfzX5db3Afa48rdNmHzT+UP3RvUXJZDqM1zEnIkSaRraWVqrUQX5oikQc9JCU/y3Od4xr936hDfs8e7+GUzA6EhmADF0r7osa+a/AITyNv3Kg= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3663.namprd11.prod.outlook.com (20.178.253.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Mon, 1 Apr 2019 12:06:01 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 12:06:01 +0000 From: "Pascal Thubert (pthubert)" To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , "Thomas Watteyne" CC: "secdispatch@ietf.org" , 6tisch <6tisch@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org> Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: 3ogcPYDenFGsRTCB8gJNHpq5AmS495mYaAMAgAAi9lA= Date: Mon, 1 Apr 2019 12:05:39 +0000 Deferred-Delivery: Mon, 1 Apr 2019 12:04:59 +0000 Message-ID: References: <1912967484.2862085.1553967089097.JavaMail.zimbra@inria.fr> <5BFE7704-2EF0-4F53-9299-299FEC3687D3@inria.fr> In-Reply-To: <5BFE7704-2EF0-4F53-9299-299FEC3687D3@inria.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.57] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa2c5450-9aaa-4649-9264-08d6b69a68d9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3663; x-ms-traffictypediagnostic: MN2PR11MB3663: x-ms-exchange-purlcount: 11 x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(346002)(396003)(376002)(199004)(189003)(9686003)(14444005)(54906003)(99286004)(54896002)(55016002)(236005)(256004)(478600001)(25786009)(7736002)(33656002)(4326008)(53936002)(966005)(66066001)(81156014)(14454004)(68736007)(6436002)(229853002)(8936002)(6306002)(74316002)(110136005)(7696005)(106356001)(81166006)(26005)(105586002)(6506007)(53546011)(186003)(6116002)(606006)(6246003)(2906002)(8676002)(76176011)(52536014)(97736004)(486006)(11346002)(86362001)(5660300002)(71190400001)(71200400001)(476003)(6666004)(446003)(316002)(3846002)(66574012)(790700001)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3663; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bgLEBWoEXknbQ6VIShMeZoRiFw0Bjb+xd1rFgPQQnmTSv9LiGJR+KuYOMcXEcNn8aWCtz15vYlKpKm9z08AeRTbEus82uRVTPuAz0DdrSXcd6YaAVjMcpzJcjhJOG297P+HZFiE1u+E6bMfiTS0VHvQ7XzPqhODV7p21DrxIE8IT5xMY4Jb3eqh4skfSKLn7ntEye8iuxmrsXevhDTBnPL/MO03+eu7zJAHQZ4pzEetRZx0hmuqyYdZbIYyNh4WGhrQh777yxVmoUT5s2iTrbW0fgbFCGu2+x7RVbpW9XtW6xAh0TVGPg6fIFCVy3AZZ2AlREYYdj8o7eD/4iSdH7sbWA4yUWzbjmZg3YqjKcJIkZg9cS75Bx7nVCXD0hzKe9LrNCUVZJM0v2Ys1SkA8CRm8cB2db5nUI6CmkYJNFMI= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa2c5450-9aaa-4649-9264-08d6b69a68d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 12:06:01.7990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3663 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 12:06:09 -0000 --_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgSSBoYWQgdGhlIGRpc2N1c3Npb24gcHJpdmF0ZWx5LCBtaW5pbWFsIHNlY3VyaXR5IGFu ZCBlZGhvYyB3ZXJlIGRpc2N1c3NlZCBhdCA2VGlTQ0ggYXQgcHJldHR5IG11Y2ggZXZlcnkgbWVl dGluZywgcGxlbmFyeSBvciBpbnRlcmltLCBzaW5jZSBhcm91bmQgSUVURiA5Ny4NCg0KVGhlIG1p bnV0ZXMgZm9yIGFuIElFVEYgYXJlIGxvY2F0ZWQgaW4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvbWludXRlcy14eC02dGlzY2gvIHdoZXJlIHh4IGlzIHRoZSBJRVRGIG51bWJlci4N ClNlZSBmb3IgaW5zdGFuY2UgSUVURiA5OCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9taW51dGVzLTk4LTZ0aXNjaC87IG9uZSBjYW4gYWxzbyBnb29nbGUgaHR0cHM6Ly93d3cuZ29v Z2xlLmNvbS9zZWFyY2g/Y2xpZW50PWZpcmVmb3gtYi1kJnE9NnRpc2NoK21pbnV0ZXMrZWRob2MN ClRoZXJlIHdhcyBhbHNvIGEgc2lkZSBtZWV0aW5nIGF0IElFVEYgMTAzLCBhbGwgcmVwb3J0ZWQg aW4gdGhlIG1pbnV0ZXMgaHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9tZWV0aW5ncy93aWtp LzE4MTEwOF9pZXRmMTAzX2Jhbmdrb2sNCg0KT25lIG1heSBhbHNvIGNvbnN1bHQgdGhlIG1pbnV0 ZXMgZnJvbSB0aGUgNlRpU0NIIFdpS2kgIGh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVl dGluZ3Mvd2lraS9icm93c2UvIHdoZXJlIGFsbCBhcmUgc3RvcmVkIHNpbmNlIGluY2VwdGlvbiBv ZiB0aGUgV0cuDQoNCkFsbCB0aGUgYmVzdCwNCg0KUGFzY2FsDQoNCkZyb206IE1hbGnFoWEgVnXE jWluacSHIDxtYWxpc2EudnVjaW5pY0BpbnJpYS5mcj4NClNlbnQ6IGx1bmRpIDEgYXZyaWwgMjAx OSAxMTo1OQ0KVG86IFRob21hcyBXYXR0ZXluZSA8dGhvbWFzLndhdHRleW5lQGlucmlhLmZyPg0K Q2M6IHNlY2Rpc3BhdGNoQGlldGYub3JnOyA2dGlzY2ggPDZ0aXNjaEBpZXRmLm9yZz47IDZ0aXNj aC1jaGFpcnMgPDZ0aXNjaC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1NlY2Rpc3Bh dGNoXSBFREhPQyBTdW1tYXJ5DQoNCisxDQoNCldlIGFyZSBoYXBweSB0byBjb250cmlidXRlIHRv IHRoaXMgZWZmb3J0IHRocm91Z2ggZmVlZGJhY2sgb24gdGhlIGRlc2lnbiwgaW1wbGVtZW50YXRp b24gZm9yIGNvbnN0cmFpbmVkIGRldmljZXMgYW5kIGl0cyBldmFsdWF0aW9uIGluIDZUaVNDSCBu ZXR3b3Jrcy4NCg0KTWFsacWhYQ0KDQpPbiAzMCBNYXIgMjAxOSwgYXQgMTg6MzEsIFRob21hcyBX YXR0ZXluZSA8dGhvbWFzLndhdHRleW5lQGlucmlhLmZyPG1haWx0bzp0aG9tYXMud2F0dGV5bmVA aW5yaWEuZnI+PiB3cm90ZToNCg0KVGhlIDZUaVNDSCBXRyBoYXMgcHJvZHVjZWQgYSBzZXQgb2Yg ZG9jdW1lbnRzIFsxLDJdIHRoYXQgc3BlY2lmeSB0aGUgdXNlIG9mIE9TQ09SRSB0byBzZWN1cmUg bWVzc2FnZSBleGNoYW5nZXMgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGluY2x1ZGluZyBuZXR3 b3JrIGFjY2Vzcy4gQXQgdGhlIHNpZGUgbWVldGluZyBpbiBQcmFndWUgdHdvIHllYXJzIGFnbyBp bnZvbHZpbmcgc2V2ZXJhbCBBRHMgYW5kIFdHIGNoYWlycywgdGhlIDZUaVNDSCBjaGFpcnMgaGF2 ZSBpbmRpY2F0ZWQgdGhlIG5lZWQgZm9yIGFuIGVmZmljaWVudCBhdXRoZW50aWNhdGVkIGtleSBl eGNoYW5nZSBwcm90b2NvbCB0aGF0IHdlIGNvdWxkIHVzZSBkdXJpbmcgdGhlIG5ldHdvcmsgYWNj ZXNzIHRvIGtleSBPU0NPUkUuIFdlIGhhdmUgYWxzbyByZXN0YXRlZCB0aGlzIHJlcXVlc3QgYXQg dGhlIFNFQ0RJU1BBVENIIGludGVyaW0gYSBjb3VwbGUgb2Ygd2Vla3MgYWdvLg0KDQpUaGUgRURI T0Mgc3BlY2lmaWNhdGlvbiB3YXMgZGlzY3Vzc2VkIG9uIG51bWVyb3VzIG9jY2FzaW9ucyBkdXJp bmcgdGhlIDZUaVNDSCB3b3JraW5nIGdyb3VwIG1lZXRpbmdzIGFuZCB0aGUgYXBwcm9hY2ggb24g dXNpbmcgaXQgZm9yIHRoZSBleHRlbnNpb24gb2YgWzFdIHRvd2FyZHMgemVyby10b3VjaCBbM10g ZGVwbG95bWVudHMgaGFkIGEgd2lkZSBjb25zZW5zdXMuIFdlIHdlbGNvbWUgdGhlIHdvcmsgaW4g dGhpcyBhcmVhIHRvIGJlIGRvbmUsIGFuZCBzdHJvbmdseSBzdXBwb3J0IGFueSBkZWNpc2lvbiBv ZiB0aGUgc2VjdXJpdHkgQURzIHRoYXQgbGVhZHMgdG8gdGhlIGZhc3QgcHJvZ3Jlc3Mgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1hbC1zZWN1cml0eS8NClsyXSBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1hcmNoaXRlY3R1cmUvDQpbM10gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtZHRzZWN1cml0 eS16ZXJvdG91Y2gtam9pbi8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdA0KU2VjZGlzcGF0Y2hAaWV0Zi5v cmc8bWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KDQo= --_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLm9i amVjdA0KCXttc28tc3R5bGUtbmFtZTpvYmplY3Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBJ IGhhZCB0aGUgZGlzY3Vzc2lvbiBwcml2YXRlbHksIG1pbmltYWwgc2VjdXJpdHkgYW5kIGVkaG9j IHdlcmUgZGlzY3Vzc2VkIGF0IDZUaVNDSCBhdCBwcmV0dHkgbXVjaCBldmVyeSBtZWV0aW5nLCBw bGVuYXJ5IG9yIGludGVyaW0sIHNpbmNlIGFyb3VuZCBJRVRGIDk3LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgbWludXRlcyBmb3IgYW4gSUVURiBhcmUgbG9jYXRlZCBpbiA8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLXh4LTZ0aXNjaC8iPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy14eC02dGlzY2gvPC9hPiB3aGVy ZSB4eCBpcyB0aGUgSUVURiBudW1iZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZWUgZm9yIGluc3RhbmNlIElFVEYgOTggPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvbWludXRlcy05OC02dGlzY2gvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL21pbnV0ZXMtOTgtNnRpc2NoLzwvYT47IG9uZSBjYW4gYWxzbyBnb29nbGUg PGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9zZWFyY2g/Y2xpZW50PWZpcmVmb3gtYi1k JmFtcDtxPTZ0aXNjaCYjNDM7bWludXRlcyYjNDM7ZWRob2MiPg0KaHR0cHM6Ly93d3cuZ29vZ2xl LmNvbS9zZWFyY2g/Y2xpZW50PWZpcmVmb3gtYi1kJmFtcDtxPTZ0aXNjaCYjNDM7bWludXRlcyYj NDM7ZWRob2M8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSB3 YXMgYWxzbyBhIHNpZGUgbWVldGluZyBhdCBJRVRGIDEwMywgYWxsIHJlcG9ydGVkIGluIHRoZSBt aW51dGVzDQo8YSBocmVmPSJodHRwczovL2JpdGJ1Y2tldC5vcmcvNnRpc2NoL21lZXRpbmdzL3dp a2kvMTgxMTA4X2lldGYxMDNfYmFuZ2tvayI+aHR0cHM6Ly9iaXRidWNrZXQub3JnLzZ0aXNjaC9t ZWV0aW5ncy93aWtpLzE4MTEwOF9pZXRmMTAzX2Jhbmdrb2s8L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uZSBtYXkgYWxzbyBjb25zdWx0IHRoZSBtaW51dGVzIGZyb20gdGhlIDZUaVNDSCBX aUtpJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mv d2lraS9icm93c2UvIj4NCmh0dHBzOi8vYml0YnVja2V0Lm9yZy82dGlzY2gvbWVldGluZ3Mvd2lr aS9icm93c2UvPC9hPiB3aGVyZSBhbGwgYXJlIHN0b3JlZCBzaW5jZSBpbmNlcHRpb24gb2YgdGhl IFdHLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIHRoZSBiZXN0LDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBNYWxpxaFhIFZ1xI1pbmnEhyAmbHQ7bWFsaXNhLnZ1Y2luaWNAaW5yaWEu ZnImZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBsdW5kaSAxIGF2cmlsIDIwMTkgMTE6NTk8YnI+DQo8 Yj5Ubzo8L2I+IFRob21hcyBXYXR0ZXluZSAmbHQ7dGhvbWFzLndhdHRleW5lQGlucmlhLmZyJmd0 Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGlzcGF0Y2hAaWV0Zi5vcmc7IDZ0aXNjaCAmbHQ7NnRpc2No QGlldGYub3JnJmd0OzsgNnRpc2NoLWNoYWlycyAmbHQ7NnRpc2NoLWNoYWlyc0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTZWNkaXNwYXRjaF0gRURIT0MgU3VtbWFyeTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgaGFwcHkgdG8gY29udHJp YnV0ZSB0byB0aGlzIGVmZm9ydCB0aHJvdWdoIGZlZWRiYWNrIG9uIHRoZSBkZXNpZ24sIGltcGxl bWVudGF0aW9uIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBpdHMgZXZhbHVhdGlvbiBpbiA2 VGlTQ0ggbmV0d29ya3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1hbGnFoWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMwIE1hciAyMDE5LCBhdCAxODoz MSwgVGhvbWFzIFdhdHRleW5lICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLndhdHRleW5lQGlu cmlhLmZyIj50aG9tYXMud2F0dGV5bmVAaW5yaWEuZnI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNGREZERkQiPlRoZSA2VGlTQ0ggV0cgaGFzIHByb2R1Y2Vk IGEgc2V0IG9mIGRvY3VtZW50cyBbMSwyXSB0aGF0IHNwZWNpZnkgdGhlIHVzZSBvZiBPU0NPUkUg dG8gc2VjdXJlIG1lc3NhZ2UgZXhjaGFuZ2VzIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBpbmNs dWRpbmcgbmV0d29yaw0KIGFjY2Vzcy4gQXQgdGhlIHNpZGUgbWVldGluZyBpbiBQcmFndWUgdHdv IHllYXJzIGFnbyBpbnZvbHZpbmcgc2V2ZXJhbCBBRHMgYW5kIFdHIGNoYWlycywgdGhlIDZUaVND SCBjaGFpcnMgaGF2ZSBpbmRpY2F0ZWQgdGhlIG5lZWQgZm9yIGFuIGVmZmljaWVudCBhdXRoZW50 aWNhdGVkIGtleSBleGNoYW5nZSBwcm90b2NvbCB0aGF0IHdlIGNvdWxkIHVzZSBkdXJpbmcgdGhl IG5ldHdvcmsgYWNjZXNzIHRvIGtleSBPU0NPUkUuIFdlIGhhdmUgYWxzbw0KIHJlc3RhdGVkIHRo aXMgcmVxdWVzdCBhdCB0aGUgU0VDRElTUEFUQ0ggaW50ZXJpbSBhIGNvdXBsZSBvZiB3ZWVrcyBh Z28uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRkRGREZEIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRkRGREZEIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNl cmlmIj5UaGUgRURIT0Mgc3BlY2lmaWNhdGlvbiB3YXMgZGlzY3Vzc2VkIG9uIG51bWVyb3VzIG9j Y2FzaW9ucyBkdXJpbmcgdGhlIDZUaVNDSCB3b3JraW5nIGdyb3VwIG1lZXRpbmdzIGFuZCB0aGUg YXBwcm9hY2ggb24gdXNpbmcgaXQgZm9yIHRoZSBleHRlbnNpb24NCiBvZiBbMV0gdG93YXJkcyB6 ZXJvLXRvdWNoIFszXSBkZXBsb3ltZW50cyBoYWQgYSB3aWRlIGNvbnNlbnN1cy4gV2Ugd2VsY29t ZSB0aGUgd29yayBpbiB0aGlzIGFyZWEgdG8gYmUgZG9uZSwgYW5kIHN0cm9uZ2x5IHN1cHBvcnQg YW55IGRlY2lzaW9uIG9mIHRoZSBzZWN1cml0eSBBRHMgdGhhdCBsZWFkcyB0byB0aGUgZmFzdCBw cm9ncmVzcyBvZiB0aGlzIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlsxXSZuYnNwOzxz cGFuIGNsYXNzPSJvYmplY3QiPjxzcGFuIHN0eWxlPSJjb2xvcjpkYXJrYmx1ZSI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtbWluaW1h bC1zZWN1cml0eS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6ZGFya2JsdWU7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtNnRpc2NoLW1pbmltYWwtc2VjdXJpdHkvPC9zcGFuPjwvYT48L3NwYW4+PC9zcGFu PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGREZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlsy XSZuYnNwOzxzcGFuIGNsYXNzPSJvYmplY3QiPjxzcGFuIHN0eWxlPSJjb2xvcjpkYXJrYmx1ZSI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlz Y2gtYXJjaGl0ZWN0dXJlLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpkYXJr Ymx1ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi02dGlzY2gtYXJjaGl0ZWN0dXJlLzwvc3Bhbj48L2E+PC9zcGFuPjwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNG REZERkQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPlszXSZuYnNwOzxzcGFuIGNsYXNzPSJvYmplY3QiPjxz cGFuIHN0eWxlPSJjb2xvcjpkYXJrYmx1ZSI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02dGlzY2gtZHRzZWN1cml0eS16ZXJvdG91Y2gtam9pbi8i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6ZGFya2JsdWU7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRp c2NoLWR0c2VjdXJpdHktemVyb3RvdWNoLWpvaW4vPC9zcGFuPjwvYT48L3NwYW4+PC9zcGFuPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTZWNkaXNwYXRjaCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U2VjZGlzcGF0Y2hAaWV0Zi5vcmciPlNl Y2Rpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2giPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2VjZGlzcGF0Y2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB35652FD7B081A56AFE3CC34DD8550MN2PR11MB3565namp_-- From nobody Tue Apr 2 02:19:06 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2A21200A2; Tue, 2 Apr 2019 02:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phKEADAtLYmA; Tue, 2 Apr 2019 02:19:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 869E412009A; Tue, 2 Apr 2019 02:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F072E660260; Tue, 2 Apr 2019 12:18:59 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFxdeGPmZdHt; Tue, 2 Apr 2019 12:18:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id CF15666012B; Tue, 2 Apr 2019 12:18:57 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> Date: Tue, 2 Apr 2019 12:18:58 +0300 Cc: "secdispatch@ietf.org" , core Content-Transfer-Encoding: quoted-printable Message-Id: <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> To: Carsten Bormann , Roman Danyliw X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Secdispatch] [core] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 09:19:04 -0000 FWIW, I had not had time to look at this during the IETF week, nor did I = have an opportunity to be at the CORE WG during the IETF. But I support = Roman's conclusion below: >> -----[ Conclusion >>=20 >> There appears to be an understood and scoped problem that is feasible = to engineer. Among the available starting points to address the problem = defined in question #1, EDHOC presents a viable choice. =20 >>=20 >> Chartering a narrowly scoped, short-lived WG in this space with EDHOC = as a starting point seems to be an attractive path forward, but we would = like to receive community feedback on the degree of support for this = approach. Jari From nobody Tue Apr 2 06:36:55 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA741200DB; Tue, 2 Apr 2019 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kkfnFz7S; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dfCA2Ns8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNg3-a6ikOkB; Tue, 2 Apr 2019 06:36:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F091200A1; Tue, 2 Apr 2019 06:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1208; q=dns/txt; s=iport; t=1554212211; x=1555421811; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4L9IPmVK2rtMbxkf3IejMVzYObwcHPOTZQL0ET3MXh4=; b=kkfnFz7SBoZtbGO3nkLQQ2yzKnEFKmItXCp7mNhKiRM86zo4WZVe23il wBx8Tk7aAz69qXewkiPwPqqGheMo5t0JwsNwEGhyQRlwH2O2ekpgvlBQF jG6uLEm9qLBlA10U0l5qMpd0L56vXPPyrIYhwBLqZBBa6xqPjJFh5IG6e U=; IronPort-PHdr: =?us-ascii?q?9a23=3A24H4IxBpKaD9EagN8PpVUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAB0ZKNc/4kNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgT1QA2h0BAsnh1UDjzWCV36WE4EugSQ?= =?us-ascii?q?DVA4BARgLCYRAAoU8IjYHDQEBAwEBCQEDAm0cDIVKAQEBAQMBATgGAQEsCwE?= =?us-ascii?q?LBAIBCBEEAQEfECcLHQgCBAENBQgMgw+BXQMVAQIMolwCihSCIIJ5AQEFhRE?= =?us-ascii?q?YggwDBYEvAYsyF4FAP4ERRoIXNT6CYQEBgWODOYImpVcJApQAlDiLRpNcAgQ?= =?us-ascii?q?CBAUCDgEBBYFUATCBVnAVO4JsggoMF4NLhRSFP3KBKI8xAQE?= X-IronPort-AV: E=Sophos;i="5.60,300,1549929600"; d="scan'208";a="253974075" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 13:36:50 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x32DaoV3031188 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 13:36:50 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 08:36:49 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 08:36:49 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 09:36:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wVeAxfFbXIJnjvnjY44Zq5o3/9eQcdM1QXLsNkkiIGA=; b=dfCA2Ns84cwDkMpbSI4GDfyfCh2be9tdFgTIy3BF7xbcP+gT2KV2oHahlGoVS9e/BRJ1nzpkHUh6f9qf/uWHffdNnE0OmKHQZ5nYjjZXYYlP/EIKB64BJgO5eNdNRJTpAsKeWV3hCWjGgJOnlRtl3dKCCX5F1BEWbcIbah8EsJk= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3886.namprd11.prod.outlook.com (20.179.150.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Tue, 2 Apr 2019 13:36:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::975:4644:7891:e2b1%3]) with mapi id 15.20.1750.017; Tue, 2 Apr 2019 13:36:47 +0000 From: "Pascal Thubert (pthubert)" To: Jari Arkko , Carsten Bormann , "Roman Danyliw" CC: "secdispatch@ietf.org" , core Thread-Topic: [core] [Secdispatch] EDHOC Summary Thread-Index: AQHU5hFZ2mc9hpxHAE2la3IM1m7wUqYonhEAgABHTHA= Date: Tue, 2 Apr 2019 13:36:37 +0000 Deferred-Delivery: Tue, 2 Apr 2019 13:36:05 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> In-Reply-To: <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4713b8a4-e963-4a8a-0b34-08d6b77040fa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3886; x-ms-traffictypediagnostic: MN2PR11MB3886: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(136003)(396003)(189003)(13464003)(199004)(7696005)(110136005)(6506007)(53546011)(54906003)(9686003)(6246003)(6306002)(68736007)(53936002)(229853002)(102836004)(71190400001)(186003)(8936002)(316002)(6436002)(76176011)(71200400001)(2906002)(97736004)(55016002)(8676002)(81156014)(81166006)(99286004)(14454004)(6116002)(6666004)(46003)(305945005)(486006)(52536014)(7736002)(478600001)(25786009)(11346002)(476003)(966005)(446003)(33656002)(4326008)(86362001)(5660300002)(106356001)(105586002)(256004)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3886; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7ETSJbSkI2I2REwxL2LViQw84SBqnd78bZbvt4awhVZTSewelX4cHJKvdtN/noIcV32eGg/vBTNXzAtgP25ih4HCRQ9OY+tmsl2a+tBsq/fvfVF3M86vcZ9EfOWorHvL8o249htLdkCGX/b3pWRWdL/36R43sLBGOZTNkA2gV0Cn9eN2tzbV/aJz9yNkf6oZ8NEEHawkDw2BJyStT5x0PNvCSBzHoCwONaRvGH9H+z0kxiq5tKlU9h7jxonnSXQ+Gyuf3y5tIOEfF+Y3QhuvqatCV0SRtJRF16yXPFJRSWA1k9zFf9rxNtrVka+VdBBSCCCiTmpzhjllW3AJ0K/230a916Q0GX/drG/r4LVVzvj7NbrEpLKS8WHHMoaP7xDpQsWfTepTtOObGb5OzfdFVjAV5UImBBuGnr4ct5rjYYo= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4713b8a4-e963-4a8a-0b34-08d6b77040fa X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 13:36:47.2031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3886 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Secdispatch] [core] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:36:54 -0000 Unsurprisingly I'm on the same page; All the best, Pascal > -----Original Message----- > From: core On Behalf Of Jari Arkko > Sent: mardi 2 avril 2019 11:19 > To: Carsten Bormann ; Roman Danyliw > Cc: secdispatch@ietf.org; core > Subject: Re: [core] [Secdispatch] EDHOC Summary >=20 > FWIW, I had not had time to look at this during the IETF week, nor did I = have > an opportunity to be at the CORE WG during the IETF. But I support Roman'= s > conclusion below: >=20 > >> -----[ Conclusion > >> > >> There appears to be an understood and scoped problem that is feasible = to > engineer. Among the available starting points to address the problem def= ined > in question #1, EDHOC presents a viable choice. > >> > >> Chartering a narrowly scoped, short-lived WG in this space with EDHOC = as a > starting point seems to be an attractive path forward, but we would like = to > receive community feedback on the degree of support for this approach. >=20 > Jari >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 2 06:49:57 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BD6120128; Tue, 2 Apr 2019 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=imt-atlantique.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqv2REqvAt1L; Tue, 2 Apr 2019 06:49:53 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ABB12010E; Tue, 2 Apr 2019 06:49:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 0305C81E84; Tue, 2 Apr 2019 15:49:51 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id nhHlUHs-GacH; Tue, 2 Apr 2019 15:49:50 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 0EC4181988; Tue, 2 Apr 2019 15:49:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 0EC4181988 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1554212990; bh=ZwJoxeS0W3TbACQQ3xXexD3KpUZQwIQPR5tmE/H4xqU=; h=MIME-Version:From:Date:Message-ID:To; b=H5DQ8czAXGEi4U2UGLDDi8XQdTVvmbf7P4Ey4gkdX18Z6v83zlCSBYQOvOTt+G8lD q2LwcNlI/MjRa4AlXELLwvZM9b2ZYVCQGzHzOL93PPxngkK/R1j+Na8Kw1gMJruST4 0x9Nth9m9HjUXlOJcmBaab6TjYEAlZuAkQ2rFp7g= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id uYZqZW_jIfRw; Tue, 2 Apr 2019 15:49:49 +0200 (CEST) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 9A43F81927; Tue, 2 Apr 2019 15:49:49 +0200 (CEST) Received: by mail-it1-f169.google.com with SMTP id 139so5297393ita.4; Tue, 02 Apr 2019 06:49:49 -0700 (PDT) X-Gm-Message-State: APjAAAX0oT6NzliH5DbuoDWCO0iWHUi6KCsoIEWJeV/k0UFWlhcrIN1q fxNa8iEqef1JiYQ/r4FuAvWvdauc4FcW1+7/e8s= X-Google-Smtp-Source: APXvYqw9vUYH31pk22z0i3oCAf0aOUohPM0f4UgZx5/6deJS8Xeoou4GfgwTaLtwA75U1dv1sU0m69+5Bmv79yPXfB4= X-Received: by 2002:a24:3d4a:: with SMTP id n71mr4394110itn.55.1554212987993; Tue, 02 Apr 2019 06:49:47 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> In-Reply-To: From: Laurent Toutain Date: Tue, 2 Apr 2019 15:49:11 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "secdispatch@ietf.org" Cc: lp-wan Content-Type: multipart/alternative; boundary="0000000000000e051405858c69c1" Archived-At: Subject: Re: [Secdispatch] [core] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:49:56 -0000 --0000000000000e051405858c69c1 Content-Type: text/plain; charset="UTF-8" Hi, I support also the creation of this WG. EDHOC is very promising for LPWAN networks. Laurent On Tue, Apr 2, 2019 at 3:37 PM Pascal Thubert (pthubert) wrote: > Unsurprisingly I'm on the same page; > > All the best, > > Pascal > > > -----Original Message----- > > From: core On Behalf Of Jari Arkko > > Sent: mardi 2 avril 2019 11:19 > > To: Carsten Bormann ; Roman Danyliw > > Cc: secdispatch@ietf.org; core > > Subject: Re: [core] [Secdispatch] EDHOC Summary > > > > FWIW, I had not had time to look at this during the IETF week, nor did I > have > > an opportunity to be at the CORE WG during the IETF. But I support > Roman's > > conclusion below: > > > > >> -----[ Conclusion > > >> > > >> There appears to be an understood and scoped problem that is feasible > to > > engineer. Among the available starting points to address the problem > defined > > in question #1, EDHOC presents a viable choice. > > >> > > >> Chartering a narrowly scoped, short-lived WG in this space with EDHOC > as a > > starting point seems to be an attractive path forward, but we would like > to > > receive community feedback on the degree of support for this approach. > > > > Jari > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000000e051405858c69c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I support also the creat= ion of this WG. EDHOC is very promising for=C2=A0 LPWAN networks. =C2=A0

Laurent

On Tue, Apr 2, 2019 at 3:37 PM= Pascal Thubert (pthubert) <pthube= rt@cisco.com> wrote:
Unsurprisingly I'm on the same page;

All the best,

Pascal

> -----Original Message-----
> From: core <core-bounces@ietf.org> On Behalf Of Jari Arkko
> Sent: mardi 2 avril 2019 11:19
> To: Carsten Bormann <cabo@tzi.org>; Roman Danyliw <rdd@cert.org>
> Cc: secdispa= tch@ietf.org; core <core@ietf.org>
> Subject: Re: [core] [Secdispatch] EDHOC Summary
>
> FWIW, I had not had time to look at this during the IETF week, nor did= I have
> an opportunity to be at the CORE WG during the IETF. But I support Rom= an's
> conclusion below:
>
> >> -----[ Conclusion
> >>
> >> There appears to be an understood and scoped problem that is = feasible to
> engineer.=C2=A0 Among the available starting points to address the pro= blem defined
> in question #1, EDHOC presents a viable choice.
> >>
> >> Chartering a narrowly scoped, short-lived WG in this space wi= th EDHOC as a
> starting point seems to be an attractive path forward, but we would li= ke to
> receive community feedback on the degree of support for this approach.=
>
> Jari
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000000e051405858c69c1-- From nobody Tue Apr 2 06:54:37 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE542120153 for ; Tue, 2 Apr 2019 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 18D9qlDVox_0 for ; Tue, 2 Apr 2019 06:54:27 -0700 (PDT) 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 85BE0120116 for ; Tue, 2 Apr 2019 06:54:26 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id m13so9060331lfb.6 for ; Tue, 02 Apr 2019 06:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PaxGD8LJFbwkPZ3WpfRDq67Wbn5MpK2aTkP2ujQqhv0=; b=Qik9KcVeBt/VwvOfQ5Ze/y6HbD1Lf3MwznmfmYvRF2Oorrq2z8gknKTIu5jW8L8zld yiPsMNE9uqXqUnaUxXm18NY6Bu/v8aaMu3e0O2YN36iemHj1Pm0/CIGJYgSh0OBXeeMi dHXRxnMGMOQtb6cdljcZqKS3BptF5ZqZHRkAdg7PuPgjjfys93oteE4mG7jkQCGtF4nq CeSCAucwD24Lr9Kb6QFnKRW3bZwl7YKk/+5clYgJSP7r4PqH69SVfco+guxKhaySs89l zxwz5Zw9myBkOVQBOghLhxTAoDyQccJBMjVHGKJKMq+u/N8FOFHh4qOFUOP89giz8DfI DgWA== 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=PaxGD8LJFbwkPZ3WpfRDq67Wbn5MpK2aTkP2ujQqhv0=; b=CEFhX3nER2aYHnNt14/Ynuz9jGaQSrgmbo6pdGk0kPVYY7xCvGTVNBlN2TL3xgmKU7 kbYhIfFYuQqKKdUA43/Xpuoyg9crh+zPyi1IoQk5LVAIoKgpjmMEaF3pxtS71hbSpGRH NooLfwLFNZfXxClsKhpBna/S+7xm2aoVPbBsSpYC/Z7vf5wm/MUVIVklSJ03qnMRNjCS bhwNcvzAs1r5SJDuYmSQQaTHN23zpK1FuieaIF/rGT1U7mDsxjo9n6/5VKOA+kEPcFrV uSzj4TYnC2EZMrscGc2Rq3e+Y8IS2/FJDrO41Z9QrNyxg9EnMW+PLA3ezsKjFAKVVP+w KPfA== X-Gm-Message-State: APjAAAWdl4uKW1BFs0gjb340LcugFnchw8WVg1zL8SNKRuBZs3WFy1Oy yfLOYY+XtxfEyi6zqd6rBhzdP1Y4aJob4cw/wn+Eeg== X-Google-Smtp-Source: APXvYqxGpUvxdTq0SiTY8fYsQD+luBuPJ6j7N+enGwbW9UAtrR6KR6TLRN+Zownj7dxrefv4GKml9Ww0WD16LJAMAYE= X-Received: by 2002:ac2:5638:: with SMTP id b24mr8302762lff.18.1554213264711; Tue, 02 Apr 2019 06:54:24 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> In-Reply-To: From: ana minaburo Date: Tue, 2 Apr 2019 15:53:58 +0200 Message-ID: To: Laurent Toutain Cc: "secdispatch@ietf.org" , lp-wan Content-Type: multipart/alternative; boundary="0000000000008c7b9d05858c7920" Archived-At: Subject: Re: [Secdispatch] [lp-wan] [core] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:54:30 -0000 --0000000000008c7b9d05858c7920 Content-Type: text/plain; charset="UTF-8" +1 Ana On Tue, Apr 2, 2019 at 3:50 PM Laurent Toutain < laurent.toutain@imt-atlantique.fr> wrote: > Hi, > > I support also the creation of this WG. EDHOC is very promising for LPWAN > networks. > > Laurent > > On Tue, Apr 2, 2019 at 3:37 PM Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Unsurprisingly I'm on the same page; >> >> All the best, >> >> Pascal >> >> > -----Original Message----- >> > From: core On Behalf Of Jari Arkko >> > Sent: mardi 2 avril 2019 11:19 >> > To: Carsten Bormann ; Roman Danyliw >> > Cc: secdispatch@ietf.org; core >> > Subject: Re: [core] [Secdispatch] EDHOC Summary >> > >> > FWIW, I had not had time to look at this during the IETF week, nor did >> I have >> > an opportunity to be at the CORE WG during the IETF. But I support >> Roman's >> > conclusion below: >> > >> > >> -----[ Conclusion >> > >> >> > >> There appears to be an understood and scoped problem that is >> feasible to >> > engineer. Among the available starting points to address the problem >> defined >> > in question #1, EDHOC presents a viable choice. >> > >> >> > >> Chartering a narrowly scoped, short-lived WG in this space with >> EDHOC as a >> > starting point seems to be an attractive path forward, but we would >> like to >> > receive community feedback on the degree of support for this approach. >> > >> > Jari >> > >> > _______________________________________________ >> > core mailing list >> > core@ietf.org >> > https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --0000000000008c7b9d05858c7920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

Ana

On Tue, Apr 2, 2019 at = 3:50 PM Laurent Toutain <laurent.toutain@imt-atlantique.fr> wrote:
Hi,

I support also the= creation of this WG. EDHOC is very promising for=C2=A0 LPWAN networks. =C2= =A0

Laurent

On Tue, Apr 2, 2019 at 3= :37 PM Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Unsurprisingly I'm on the same page;

All the best,

Pascal

> -----Original Message-----
> From: core <core-bounces@ietf.org> On Behalf Of Jari Arkko
> Sent: mardi 2 avril 2019 11:19
> To: Carsten Bormann <cabo@tzi.org>; Roman Danyliw <rdd@cert.org>
> Cc: secdispa= tch@ietf.org; core <core@ietf.org>
> Subject: Re: [core] [Secdispatch] EDHOC Summary
>
> FWIW, I had not had time to look at this during the IETF week, nor did= I have
> an opportunity to be at the CORE WG during the IETF. But I support Rom= an's
> conclusion below:
>
> >> -----[ Conclusion
> >>
> >> There appears to be an understood and scoped problem that is = feasible to
> engineer.=C2=A0 Among the available starting points to address the pro= blem defined
> in question #1, EDHOC presents a viable choice.
> >>
> >> Chartering a narrowly scoped, short-lived WG in this space wi= th EDHOC as a
> starting point seems to be an attractive path forward, but we would li= ke to
> receive community feedback on the degree of support for this approach.=
>
> Jari
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan
--0000000000008c7b9d05858c7920-- From nobody Wed Apr 3 00:59:15 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D731120154; Wed, 3 Apr 2019 00:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPFX-eb1YFN2; Wed, 3 Apr 2019 00:59:03 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 C38A9120144; Wed, 3 Apr 2019 00:59:02 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id d26so13989151ede.10; Wed, 03 Apr 2019 00:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dlL87f2Cd6tJ4WV9dmFoR8Z2xEq7TR7OqUMTTj/4la8=; b=HljfZHZb536kk9k1N6G0gqv60zJ+Ez9cRR4zKePlHZ36ZLY8letSrgfOFQK7FFt71F 2ZVBpwxhXiKiMQ0FDi/LK+iZGCWBazGgAl4LAznkQGe0Ip2lHAoVXx1KJ6yEpvOylotb BcsWgIsaNzbZbHw5hk4mO/yloYmljN9NBM8UcDoa3dc2bY3DtHUTf7MjtQKxEGj4rAqL D38da9ouGzbytsxTkTJiz/CbCmDYir1S8a9F30dWHFoDQg3NAWHvaylbi8BiLtEYM2Ro LZkFEftZOJKmlW1ndWIYUC5PkaaLjlQ7bfVjHIRyxHO4PpY8arpMsSwS9eEu7AA17KZ2 assw== 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=dlL87f2Cd6tJ4WV9dmFoR8Z2xEq7TR7OqUMTTj/4la8=; b=gyw2Y+kP4jEXo8kspg2oT0OzcRAOO1qmWkHb5CnMEsR4NtWccRl631/F4cQCIeEQ9m 3Vz1Sl9N5yTyRI5tF9HQNwlerKeuIIUQM7rn9aKLMKK4RfSBR96XErPjz9tM1fGDZ4iD Gdv91kTBHITHnds5t/pARFWRXXM0aj1ktZ8TcWBavVjnuDkdIBLsXJT4igasixY4dvSw 2msT0rRio+QlGypC4L0F8Hs42h/dD741J98Mm79Hbz0Zwu5wFZtE0OD6CVIVKaNEz9m/ Zqj6yXsITT5+fTiPXucN+4oEkZ1AfGHF+JAJaa6XqSW5fda0MA4NOeYUroW6yumIpW42 FXVg== X-Gm-Message-State: APjAAAXZ6cM02kA72VQKtSovlNdTKfq5msvVd7IIfPSRxubJ6bAoi7kD B3ZsR4c1Mw3zxwtglirHYAqOXxzxfdYyQ2d06LVRbD+l9jw= X-Google-Smtp-Source: APXvYqwexaGIo2g5SLfqp6Lpkkg8PGYnXw8AEV+KfT3toiF0SaHJNjbyFd3NgW71O+F3568EpVn73ZpoWovEAYF/b30= X-Received: by 2002:a17:906:2cd1:: with SMTP id r17mr5365509ejr.101.1554278340834; Wed, 03 Apr 2019 00:59:00 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> In-Reply-To: From: Renzo Navas Date: Wed, 3 Apr 2019 09:58:49 +0200 Message-ID: To: "secdispatch@ietf.org" Cc: lp-wan Content-Type: multipart/alternative; boundary="000000000000633a0905859ba0ac" Archived-At: Subject: Re: [Secdispatch] [lp-wan] [core] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 07:59:06 -0000 --000000000000633a0905859ba0ac Content-Type: text/plain; charset="UTF-8" Hi all, for what it's worth, +1 with Roman regards, Renzo On Tue, Apr 2, 2019 at 3:54 PM ana minaburo wrote: > +1 > > Ana > > On Tue, Apr 2, 2019 at 3:50 PM Laurent Toutain < > laurent.toutain@imt-atlantique.fr> wrote: > >> Hi, >> >> I support also the creation of this WG. EDHOC is very promising for >> LPWAN networks. >> >> Laurent >> >> On Tue, Apr 2, 2019 at 3:37 PM Pascal Thubert (pthubert) < >> pthubert@cisco.com> wrote: >> >>> Unsurprisingly I'm on the same page; >>> >>> All the best, >>> >>> Pascal >>> >>> > -----Original Message----- >>> > From: core On Behalf Of Jari Arkko >>> > Sent: mardi 2 avril 2019 11:19 >>> > To: Carsten Bormann ; Roman Danyliw >>> > Cc: secdispatch@ietf.org; core >>> > Subject: Re: [core] [Secdispatch] EDHOC Summary >>> > >>> > FWIW, I had not had time to look at this during the IETF week, nor did >>> I have >>> > an opportunity to be at the CORE WG during the IETF. But I support >>> Roman's >>> > conclusion below: >>> > >>> > >> -----[ Conclusion >>> > >> >>> > >> There appears to be an understood and scoped problem that is >>> feasible to >>> > engineer. Among the available starting points to address the problem >>> defined >>> > in question #1, EDHOC presents a viable choice. >>> > >> >>> > >> Chartering a narrowly scoped, short-lived WG in this space with >>> EDHOC as a >>> > starting point seems to be an attractive path forward, but we would >>> like to >>> > receive community feedback on the degree of support for this approach. >>> > >>> > Jari >>> > >>> > _______________________________________________ >>> > core mailing list >>> > core@ietf.org >>> > https://www.ietf.org/mailman/listinfo/core >>> >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch >>> >> _______________________________________________ >> lp-wan mailing list >> lp-wan@ietf.org >> https://www.ietf.org/mailman/listinfo/lp-wan >> > _______________________________________________ > lp-wan mailing list > lp-wan@ietf.org > https://www.ietf.org/mailman/listinfo/lp-wan > --000000000000633a0905859ba0ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all, for what it's worth,=C2=A0
+1 with=C2=A0Roman=C2=A0

re= gards,
Renzo
=

= On Tue, Apr 2, 2019 at 3:54 PM ana minaburo <ana@ackl.io> wrote:
+1

Ana
On Tue, = Apr 2, 2019 at 3:50 PM Laurent Toutain <laurent.toutain@imt-atlantique.fr> wrote:
Hi,

I support also the creation= of this WG. EDHOC is very promising for=C2=A0 LPWAN networks. =C2=A0
<= /div>

Laurent

On Tue, Apr 2, 2019 at 3:37 PM Pa= scal Thubert (pthubert) <pthubert@cisco.com> wrote:
Unsurprisingly I'm on the same page;

All the best,

Pascal

> -----Original Message-----
> From: core <core-bounces@ietf.org> On Behalf Of Jari Arkko
> Sent: mardi 2 avril 2019 11:19
> To: Carsten Bormann <cabo@tzi.org>; Roman Danyliw <rdd@cert.org>
> Cc: secdispa= tch@ietf.org; core <core@ietf.org>
> Subject: Re: [core] [Secdispatch] EDHOC Summary
>
> FWIW, I had not had time to look at this during the IETF week, nor did= I have
> an opportunity to be at the CORE WG during the IETF. But I support Rom= an's
> conclusion below:
>
> >> -----[ Conclusion
> >>
> >> There appears to be an understood and scoped problem that is = feasible to
> engineer.=C2=A0 Among the available starting points to address the pro= blem defined
> in question #1, EDHOC presents a viable choice.
> >>
> >> Chartering a narrowly scoped, short-lived WG in this space wi= th EDHOC as a
> starting point seems to be an attractive path forward, but we would li= ke to
> receive community feedback on the degree of support for this approach.=
>
> Jari
>
> _______________________________________________
> core mailing list
> core@ietf.org > https://www.ietf.org/mailman/listinfo/core

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan
_______________________________________________
lp-wan mailing list
lp-wan@ietf.org https://www.ietf.org/mailman/listinfo/lp-wan
--000000000000633a0905859ba0ac-- From nobody Wed Apr 3 12:45:00 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559781205CD for ; Wed, 3 Apr 2019 12:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w76Pww9LK8zs for ; Wed, 3 Apr 2019 12:44:57 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 671F51205CC for ; Wed, 3 Apr 2019 12:44:57 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x33JiuwS039717 for ; Wed, 3 Apr 2019 15:44:56 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x33JiuwS039717 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1554320696; bh=HPZVIXmqVHC891D1Nqhq1QnbOm5Us4/mwex4nQwpYVI=; h=From:To:Subject:Date:References:In-Reply-To:From; b=MNtBLF+bEdI8lAobI+sF4wuQbOVdBxH0Xy185fmlKCLODrtIpLqQtPK3Q4exkF0kR DJ/0BPg1SuUWhprEL2hAQBmyT0rtk9xHVp9HSwCJfziESEfDpAjzvW9RaFjH6dqtvk NhuG1iRxBQ+KYJtKYl86N3NWHA0GRlEddkTDmozc= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x33JirXJ027179 for ; Wed, 3 Apr 2019 15:44:53 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Wed, 3 Apr 2019 15:44:53 -0400 From: Roman Danyliw To: "secdispatch@ietf.org" Thread-Topic: EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAFBp0NQ Date: Wed, 3 Apr 2019 19:44:51 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B331B9CE@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 19:44:59 -0000 Hello! > -----Original Message----- > From: Secdispatch [mailto:secdispatch-bounces@ietf.org] On Behalf Of > Roman Danyliw > Sent: Thursday, March 28, 2019 6:32 AM > To: secdispatch@ietf.org > Subject: [Secdispatch] EDHOC Summary >=20 > Hi! >=20 > We have observed the continued discussion and interest in the topics > discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. Our > assessment of the current state of this discuss and as well as proposed n= ext > steps are below. [snip] Thanks for all of the feedback so far. We would appreciate any additional = thoughts by Monday, April 15, 2019. Regards, Roman and Ben From nobody Mon Apr 8 05:45:30 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543861202E9 for ; Mon, 8 Apr 2019 05:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] 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 NmFWeXr-BF7R for ; Mon, 8 Apr 2019 05:45:24 -0700 (PDT) Received: from SELDSEGREL01.sonyericsson.com (seldsegrel01.sonyericsson.com [37.139.156.29]) (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 DA948120086 for ; Mon, 8 Apr 2019 05:45:23 -0700 (PDT) From: "Blomqvist, Peter" To: "secdispatch@ietf.org" Thread-Topic: EDHOC Summary Thread-Index: AQHU7gjfjYu/9gjWPE2SJcZO0X/GVg== Date: Mon, 8 Apr 2019 12:45:20 +0000 Message-ID: <1554727520439.48462@sony.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <438BFA1F-5EA3-4B8E-A04F-EF643A8725E3@tzi.org> <721CFE5F-9E3D-4FBA-8A27-D8D975903B38@piuha.net> , In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.18.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 12:45:27 -0000 ?We support the forming of a WG for EDHOC. Best Peter From nobody Mon Apr 8 07:00:46 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2135A120310 for ; Mon, 8 Apr 2019 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=risecloud.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 V1tGzCYNg4o6 for ; Mon, 8 Apr 2019 07:00:40 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3AA1202E9 for ; Mon, 8 Apr 2019 07:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ey/m+3iwBqlavvNmcMFbLZhfzpRaqapgqMvw++EyOfo=; b=YeiZEjzk5HZdvs/7WxygVqe05ondVDyZrh9+3zFS5FEhhs3OO7d4v2feYEBPMoeqhmnr4LAZvxdjg09/hzoU/NiiwcdVfnrl1qYY/qPH0emQkDhxU3HVypkGHLctbmNzKN06C110m6OzyOV5ZhabZO0al1uB/MuWFA0NWwRaMH8= Received: from DB6P18901CA0014.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::24) by DB6P18901MB0102.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:28::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Mon, 8 Apr 2019 14:00:37 +0000 Received: from AM5EUR02FT015.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::204) by DB6P18901CA0014.outlook.office365.com (2603:10a6:4:16::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15 via Frontend Transport; Mon, 8 Apr 2019 14:00:37 +0000 Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=bestguesspass action=none header.from=ri.se; Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se; Received: from mail.ri.se (194.218.146.197) by AM5EUR02FT015.mail.protection.outlook.com (10.152.8.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1771.16 via Frontend Transport; Mon, 8 Apr 2019 14:00:36 +0000 Received: from sp-mail-1.sp.se (10.100.0.161) by sp-mail-1.sp.se (10.100.0.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 8 Apr 2019 16:00:36 +0200 Received: from sp-mail-1.sp.se ([fe80::7d78:8db6:13df:8cc7]) by sp-mail-1.sp.se ([fe80::7d78:8db6:13df:8cc7%21]) with mapi id 15.01.1713.004; Mon, 8 Apr 2019 16:00:36 +0200 From: Shahid Raza To: Roman Danyliw CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAFBp0NQAOtdqYA= Date: Mon, 8 Apr 2019 14:00:35 +0000 Message-ID: <131B4367-8F17-47BE-8473-9970D4924A04@ri.se> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <359EC4B99E040048A7131E0F4E113AFC01B331B9CE@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B331B9CE@marchand> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.102.3) x-originating-ip: [10.100.0.67] Content-Type: multipart/alternative; boundary="_000_131B43678F1747BE84739970D4924A04rise_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(136003)(2980300002)(13464003)(199004)(189003)(40036005)(44832011)(53376002)(53386004)(69596002)(84326002)(4326008)(68736007)(83716004)(186003)(236005)(478600001)(966005)(106002)(33656002)(106466001)(74482002)(36756003)(336012)(2906002)(71190400001)(6916009)(54896002)(6306002)(6246003)(486006)(11346002)(22756006)(26005)(82746002)(2616005)(126002)(476003)(53936002)(66574012)(356004)(446003)(102836004)(53546011)(97736004)(606006)(16586007)(6116002)(3846002)(5660300002)(7736002)(33964004)(53416004)(316002)(76176011)(81166006)(57306001)(14454004)(733005)(50226002)(8936002)(81156014)(229853002)(8676002)(14444005)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P18901MB0102; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ccf7a7b0-a103-4f36-aeda-08d6bc2a934e X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4709054)(2017052603328)(7193020); SRVR:DB6P18901MB0102; X-MS-TrafficTypeDiagnostic: DB6P18901MB0102: X-MS-Exchange-PUrlCount: 3 X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0001227049 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: KD1KwBXtj+8wQmrAIbvbdUp8YMhw+tQQ89hteL9e3GzAVSRVN4CODpHgP3icxzXEhT5zCV6hcTCpdYdbQWluW/PvXUiFW5EREqib6j/A6mQixOSfpNGUScHKNqNS2QheBE94Len5hLPoDqLLK629OTY+jQtQrVtYK1wyWpZkwEpzaH/6Dl7BgMf+79i0F6xdWESLUDBUSqB2CfO79yc5bj8km2hE6ic60hLvOoFE/HXWED8c6LGp0dskLbcLgUzQJco+v0rZW+GQ5ZCHLZBi/h5WOkL+weAqYaX4l4KVQ0clT+q5ZvhdbD0fqMB5I+rn8G13EB9BDdmVGy3JVOqRd8Jne4DvgXCP9BotBPdTzX5rPSF1WA7shNeCLIdbW2eGbB2D3CuFmQ9FXqGOK7cgscSeLAHfwig/ej4/cNS6Y2c= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2019 14:00:36.4838 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ccf7a7b0-a103-4f36-aeda-08d6bc2a934e X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0102 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 14:00:44 -0000 --_000_131B43678F1747BE84739970D4924A04rise_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCldlIGFyZSB3b3JraW5nIG9uIHRoZSBpbnRlZ3JhdGlvbiBvZiBPU0NPUkUgaW4gdGhlIElU VSAoSW50ZWxsaWdlbnQgVHJhbnNwb3J0YXRpb24gVW5pb24pIHdvcmxkLg0KU3RhbmRhcmRpc2Vk IEVESE9DIHdpbGwgY2VydGFpbmx5IGFkZCBhIG1pc3NpbmcgcGllY2UuDQoNCkJlc3QsDQpTaGFo aWQNCg0KDQpTaGFoaWQgUmF6YSwgUGhEDQpEaXJlY3RvciBTZWN1cml0eSBMYWIgYW5kIEV4cGVy dCBSZXNlYXJjaGVyDQpSSVNFIC0gUmVzZWFyY2ggSW5zdGl0dXRlcyBvZiBTd2VkZW4NCkRpdmlz aW9uIElDVCAtIFJJU0UgU0lDUw0KDQpbUklTRSBsb2dvXSAgICAgSXNhZmpvcmRzZ2F0YW4gMjIg LyBLaXN0YWfDpW5nZW4gMTYNCjE2NDQwLCBLaXN0YSBTdG9ja2hvbG0NCk1vYmlsZTogKzQ2IDc2 ODgzMTc5Nw0Kc2hhaGlkLnJhemFAcmkuc2UgPG1haWx0bzpzaGFoaWRAc2ljcy5zZT4NCmh0dHA6 Ly93d3cuc2hhaGlkcmF6YS5uZXQNCmh0dHA6Ly93d3cuc2ljcy5zZQ0KDQpUaGUgUklTRSBpbnN0 aXR1dGVzIElubnZlbnRpYSwgU1AgYW5kIFN3ZWRpc2ggSUNUIGhhdmUgbWVyZ2VkIGluIG9yZGVy IHRvIGJlY29tZSBhIHN0cm9uZ2VyIHJlc2VhcmNoIGFuZCBpbm5vdmF0aW9uIHBhcnRuZXIgZm9y IGJ1c2luZXNzZXMgYW5kIHNvY2lldHkuDQoNCk9uIDMgQXByIDIwMTksIGF0IDIxOjQ0LCBSb21h biBEYW55bGl3IDxyZGRAY2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0Lm9yZz4+IHdyb3RlOg0KDQpI ZWxsbyENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNlY2Rpc3BhdGNoIFtt YWlsdG86c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQpSb21hbiBE YW55bGl3DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjgsIDIwMTkgNjozMiBBTQ0KVG86IHNlY2Rp c3BhdGNoQGlldGYub3JnPG1haWx0bzpzZWNkaXNwYXRjaEBpZXRmLm9yZz4NClN1YmplY3Q6IFtT ZWNkaXNwYXRjaF0gRURIT0MgU3VtbWFyeQ0KDQpIaSENCg0KV2UgaGF2ZSBvYnNlcnZlZCB0aGUg Y29udGludWVkIGRpc2N1c3Npb24gYW5kIGludGVyZXN0IGluIHRoZSB0b3BpY3MNCmRpc2N1c3Nl ZCBhdCB0aGUgTWFyY2ggMjAxOSBWaXJ0dWFsIEludGVyaW0gU2VjZGlzcGF0Y2ggbWVldGluZyBb MV0uICBPdXINCmFzc2Vzc21lbnQgb2YgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhpcyBkaXNjdXNz IGFuZCBhcyB3ZWxsIGFzIHByb3Bvc2VkIG5leHQNCnN0ZXBzIGFyZSBiZWxvdy4NCg0KW3NuaXBd DQoNClRoYW5rcyBmb3IgYWxsIG9mIHRoZSBmZWVkYmFjayBzbyBmYXIuICBXZSB3b3VsZCBhcHBy ZWNpYXRlIGFueSBhZGRpdGlvbmFsIHRob3VnaHRzIGJ5IE1vbmRheSwgQXByaWwgMTUsIDIwMTku DQoNClJlZ2FyZHMsDQpSb21hbiBhbmQgQmVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpTZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QNClNlY2Rpc3Bh dGNoQGlldGYub3JnPG1haWx0bzpTZWNkaXNwYXRjaEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2gNCg0K --_000_131B43678F1747BE84739970D4924A04rise_ Content-Type: text/html; charset="utf-8" Content-ID: <9C455265ECA72446B5F295E8165329E8@ri.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCiYjNDM7MTxiciBjbGFzcz0iIj4NCldlIGFyZSB3 b3JraW5nIG9uIHRoZSBpbnRlZ3JhdGlvbiBvZiBPU0NPUkUgaW4gdGhlIElUVSAoSW50ZWxsaWdl bnQgVHJhbnNwb3J0YXRpb24gVW5pb24pIHdvcmxkLiZuYnNwOw0KPGRpdiBjbGFzcz0iIj5TdGFu ZGFyZGlzZWQgRURIT0Mgd2lsbCBjZXJ0YWlubHkgYWRkIGEgbWlzc2luZyBwaWVjZS4mbmJzcDs8 YnIgY2xhc3M9IiI+DQo8Zm9udCBjb2xvcj0iIzU4NTZkNiIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9mb250PkJlc3QsPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+U2hhaGlkJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazog YWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7 IiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iIzQxNDE0MSIgY2xhc3M9IiI+U2hhaGlkIFJhemEsIFBo RA0KPGJyIGNsYXNzPSIiPg0KPC9mb250Pjwvc3Bhbj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Y29sb3I6IHJnYig2NSwgNjUsIDY1KTsgZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+RGlyZWN0 b3IgU2VjdXJpdHkgTGFiIGFuZCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2 NSwgNjUsIDY1KTsgZm9udC1zaXplOiAxMXB4OyIgY2xhc3M9IiI+RXhwZXJ0IFJlc2VhcmNoZXI8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPjxmb250IGNvbG9y PSIjNDE0MTQxIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9zcGFuPjwvaT48YiBj bGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2NSwgNjUsIDY1KTsgZm9udC1zaXplOiAx MXB4OyIgY2xhc3M9IiI+UklTRSAtIFJlc2VhcmNoIEluc3RpdHV0ZXMgb2YgU3dlZGVuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHg7IiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iIzQx NDE0MSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250Pjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoNjUsIDY1LCA2NSk7IGZvbnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPkRp dmlzaW9uIElDVCAtIFJJU0UgU0lDUzwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9IiI+DQo8dGJv ZHkgY2xhc3M9IiI+DQo8dHIgY2xhc3M9IiI+DQo8dGQgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFweDsiIGNsYXNzPSIiPjxmb250IGNvbG9yPSIjNDE0MTQxIiBjbGFzcz0iIj48 aW1nIHNyYz0iaHR0cDovL3NoYWhpZHJhemEubmV0L1JJU0UtbG9nby5wbmciIGFsdD0iUklTRSBs b2dvIiB3aWR0aD0iNTUiIGhlaWdodD0iNzEiIGNsYXNzPSIiPiAmbmJzcDs8L2ZvbnQ+PC9zcGFu PjwvdGQ+DQo8dGQgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsiIGNsYXNz PSIiPjxmb250IGNvbG9yPSIjNDE0MTQxIiBjbGFzcz0iIj5Jc2Fmam9yZHNnYXRhbiAyMiAvIEtp c3RhZ8OlbmdlbiAxNiZuYnNwOzxiciBjbGFzcz0iIj4NCjE2NDQwLCBLaXN0YSBTdG9ja2hvbG0m bmJzcDs8YnIgY2xhc3M9IiI+DQpNb2JpbGU6ICYjNDM7NDYgNzY4ODMxNzk3Jm5ic3A7PGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnNoYWhpZEBzaWNzLnNlICIgY2xhc3M9IiI+c2hhaGlk LnJhemFAcmkuc2UmbmJzcDs8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5z aGFoaWRyYXphLm5ldCIgY2xhc3M9IiI+aHR0cDovL3d3dy5zaGFoaWRyYXphLm5ldDwvYT4mbmJz cDs8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vd3d3LnNpY3Muc2UiIGNsYXNzPSIiPmh0 dHA6Ly93d3cuc2ljcy5zZTwvYT4mbmJzcDs8L2ZvbnQ+PC9zcGFuPjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iIj48ZW0gc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsi IGNsYXNzPSIiPjxmb250IGNvbG9yPSIjNDE0MTQxIiBjbGFzcz0iIj5UaGUgUklTRSBpbnN0aXR1 dGVzIElubnZlbnRpYSwgU1AgYW5kIFN3ZWRpc2ggSUNUIGhhdmUgbWVyZ2VkIGluIG9yZGVyIHRv IGJlY29tZSBhIHN0cm9uZ2VyIHJlc2VhcmNoIGFuZCBpbm5vdmF0aW9uIHBhcnRuZXIgZm9yIGJ1 c2luZXNzZXMgYW5kIHNvY2lldHkuPC9mb250PjwvZW0+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDMgQXByIDIwMTksIGF0IDIxOjQ0LCBSb21hbiBE YW55bGl3ICZsdDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQub3JnIiBjbGFzcz0iIj5yZGRAY2Vy dC5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IZWxsbyE8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IFNlY2Rpc3BhdGNoIFs8 YSBocmVmPSJtYWlsdG86c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bWFp bHRvOnNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8YnIgY2xh c3M9IiI+DQpSb21hbiBEYW55bGl3PGJyIGNsYXNzPSIiPg0KU2VudDogVGh1cnNkYXksIE1hcmNo IDI4LCAyMDE5IDY6MzIgQU08YnIgY2xhc3M9IiI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNlY2Rp c3BhdGNoQGlldGYub3JnIiBjbGFzcz0iIj5zZWNkaXNwYXRjaEBpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQpTdWJqZWN0OiBbU2VjZGlzcGF0Y2hdIEVESE9DIFN1bW1hcnk8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpIaSE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXZSBoYXZl IG9ic2VydmVkIHRoZSBjb250aW51ZWQgZGlzY3Vzc2lvbiBhbmQgaW50ZXJlc3QgaW4gdGhlIHRv cGljczxiciBjbGFzcz0iIj4NCmRpc2N1c3NlZCBhdCB0aGUgTWFyY2ggMjAxOSBWaXJ0dWFsIElu dGVyaW0gU2VjZGlzcGF0Y2ggbWVldGluZyBbMV0uICZuYnNwO091cjxiciBjbGFzcz0iIj4NCmFz c2Vzc21lbnQgb2YgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhpcyBkaXNjdXNzIGFuZCBhcyB3ZWxs IGFzIHByb3Bvc2VkIG5leHQ8YnIgY2xhc3M9IiI+DQpzdGVwcyBhcmUgYmVsb3cuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KW3NuaXBdPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhhbmtzIGZvciBhbGwgb2YgdGhlIGZlZWRiYWNrIHNvIGZhci4gJm5i c3A7V2Ugd291bGQgYXBwcmVjaWF0ZSBhbnkgYWRkaXRpb25hbCB0aG91Z2h0cyBieSBNb25kYXks IEFwcmlsIDE1LCAyMDE5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJlZ2FyZHMsPGJy IGNsYXNzPSIiPg0KUm9tYW4gYW5kIEJlbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv OlNlY2Rpc3BhdGNoQGlldGYub3JnIiBjbGFzcz0iIj5TZWNkaXNwYXRjaEBpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rp c3BhdGNoPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_131B43678F1747BE84739970D4924A04rise_-- From nobody Mon Apr 8 08:23:42 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D60120106 for ; Mon, 8 Apr 2019 08:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01] 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 piwFdiNhyspt for ; Mon, 8 Apr 2019 08:23:37 -0700 (PDT) Received: from SELDSEGREL01.sonyericsson.com (seldsegrel01.sonyericsson.com [37.139.156.29]) (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 B8C0412008C for ; Mon, 8 Apr 2019 08:23:36 -0700 (PDT) From: "Blomqvist, Peter" To: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTuHNnZeJo8GkxQSjCOyScopZI0cQ== Date: Mon, 8 Apr 2019 15:23:34 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.18.4] Content-Type: multipart/alternative; boundary="_000_d741d224c8324c3f8a300c467a836913seldmbx10corpusersnet_" MIME-Version: 1.0 Archived-At: Subject: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 15:23:40 -0000 --_000_d741d224c8324c3f8a300c467a836913seldmbx10corpusersnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was requested to elaborate on our use-cases for EDHOC: We believe that EDHOC & OSCORE enables lightweight key exchange and E2E se= curity for battery constrained devices running over cellular IoT ( NB-IoT and/or Cat M1) Best Peter --_000_d741d224c8324c3f8a300c467a836913seldmbx10corpusersnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was requested to elaborate on= our use-cases for EDHOC:

We believe that EDHOC  &am= p; OSCORE enables lightweight key exchange and E2E security for battery con= strained devices

running over cellular IoT ( NB-= IoT and/or Cat M1)

 

Best

Peter

--_000_d741d224c8324c3f8a300c467a836913seldmbx10corpusersnet_-- From nobody Mon Apr 8 12:43:15 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E7512043E for ; Mon, 8 Apr 2019 12:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBDIlNxpn7oD for ; Mon, 8 Apr 2019 12:43:11 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 AB2CB12043A for ; Mon, 8 Apr 2019 12:43:11 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id 103so13313993otd.9 for ; Mon, 08 Apr 2019 12:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ub9a1bPUnuVvqJ/MQorJ9eL0OYvnz/fiWIJD73JKdvs=; b=Bl+OKZmzre0l+nX2p9LSYQj2fpmtA693sju+Drnjko3hSXzH2yASZ2DuGoJyrDmRen K0bwToYBMXam8FhPt9A3sz2ueVrdrMG5ZnypQ36VDbX9Pq9KEuv52rnO5mEgUPVJoTUt s78e9c4bMujQ+qXa+zEwUZJ3m7E+Nqln5kBzmez3zg0Khic7VIicuKMQ1SmuCFBqBVnk wft2PgADrlR4Mgf6gl65o/gJrMtjakPp41vCNdoi1inOoqWScTWpsAvnTM9ZxTKGMmb4 9g4uvI6yiCufiOfy++A7GUHuxqxthO8pQTi7R+2A6l3EXrDJ1dR+CCd0SFCXrtR/ZFDN XDGA== 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=Ub9a1bPUnuVvqJ/MQorJ9eL0OYvnz/fiWIJD73JKdvs=; b=FzCQlK7wM7eeLBaMIUK25PENiHod3WxYGkCqv8rilvLAHqcrH4c2FDUJrJ1/DzGni+ EPB6+jZ0ByPyxAPoyYhoqUDtNAOP/+AHzRcnztb01pyPMJX/bcCuyh87gHfxNxd/hpL1 88fmsszfQPJCm+klEr/1FGkhTjmQF+Ed+mbXQn78agx13wDwnj/2NscPv/06UrrSd6aq pypMSrTlczr7EoEI9jPWv9UxNiHodE2+zC3KvMXO1zlVTspKgt4XYZtiYKfSO8Ino7ps xoNwy91i9IkD05CG9YDgtlJpcIPAB2GKU3MzbhKpVBgAZKQVe0jcNjFUBieaVuOzAMsu MY5g== X-Gm-Message-State: APjAAAXkt+vJUju7Zf6Moi0W6zKEZHBJagJgfGWItNSEFYu3BLHxnxaH pBsXrcrl6JtOHUs12iI4f4eiYc7LTyFySTlJJDjUPw== X-Google-Smtp-Source: APXvYqyuwQ5jv9eA6IInptZm/fn7tyoIEy1gZlZbXh/G1a/Ee+yQmewxgKUmfYKj/MImpLMycBegTyeYIdnmDhRM5aY= X-Received: by 2002:a9d:74d6:: with SMTP id a22mr18867866otl.336.1554752590919; Mon, 08 Apr 2019 12:43:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 8 Apr 2019 15:42:56 -0400 Message-ID: To: "Blomqvist, Peter" Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e54ce405860a0b79" Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 19:43:14 -0000 --000000000000e54ce405860a0b79 Content-Type: text/plain; charset="UTF-8" Hi Peter, I think a little more elaboration might be helpful :) What constraints are these devices facing? E.g., in terms of transports, code footprint. Thanks, --Richard On Mon, Apr 8, 2019 at 11:23 AM Blomqvist, Peter wrote: > I was requested to elaborate on our use-cases for EDHOC: > > We believe that EDHOC & OSCORE enables lightweight key exchange and E2E > security for battery constrained devices > > running over cellular IoT ( NB-IoT and/or Cat M1) > > > > Best > > Peter > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000e54ce405860a0b79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

I think a little m= ore elaboration might be helpful :)=C2=A0 What constraints are these device= s facing?=C2=A0 E.g., in terms of transports, code footprint.
Thanks,
--Richard

On Mon, Apr 8, 2019 at 11:= 23 AM Blomqvist, Peter <Pete= r.Blomqvist@sony.com> wrote:

I was requested to elaborate on= our use-cases for EDHOC:

We believe that EDHOC =C2=A0&am= p; OSCORE enables lightweight key exchange and E2E security for battery con= strained devices

running over cellular IoT ( NB-= IoT and/or Cat M1)

=C2=A0

Best

Peter

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000e54ce405860a0b79-- From nobody Mon Apr 8 16:17:52 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B594120125 for ; Mon, 8 Apr 2019 16:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=NxNbnfvq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E63th2Aa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_BX6I3Nys7Q for ; Mon, 8 Apr 2019 16:17:47 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E984120123 for ; Mon, 8 Apr 2019 16:17:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 958A5934 for ; Mon, 8 Apr 2019 19:17:46 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 19:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=zD6cd jyfd6UnyLfivOEblQ3yfn/YACa8FqFVQNgGmHQ=; b=NxNbnfvq5MfhrDbZ8uYFB 5XTziajTDVvAECxgs92TPGqQeFg7bskvs65hHGrCVrM30luB7qYBWzeMqBLxhL1u YfO486yHQXHTst3OZ2lkakYwPrmaYz5kt7qwwfRqIJ0d5GlukRqXO9if4s2jzp2b 4p9g0cjvVXjeqr87KdKIqMjdNcjcc/kVzIZfudKp2AVq/bUMTyimD0iQm5PDfiMc bbHMsriYkxXXnK98TpbtrzJBDQrKySRHZaqONKWSnkU56uQ1N3qqaC1CDGxTU8il KEq6VvvXoKdZxGqmBBjN9hRbFSaQfip9byQs4+Vtz4pWxPqnWh94yOdSeiP8O6ik g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=zD6cdjyfd6UnyLfivOEblQ3yfn/YACa8FqFVQNgGm HQ=; b=E63th2AaA3pFtGEMZdu8Dz4A08DS4NVAtnF6qX/KKoa+xIFzP9pgBFXVV KyPm/wxuGCv5+sgwjN9MWEJ+uEZ3JXHBrs5/6OPM/LU6qU/xoNRP0oE70N6/aK8P J+qKt7tDFAxDCyb9ee5WXhGu245nk1PYbyopbsJdegP/B7WD0/f5mpcHgF5FVfZf pZyQG+FaFuCxW19VcRDyQXebzlRLeaiNUm4RoSea9Jk3u6W/lBZe/lHlAdfiDEjM 5lMpg7czRvIIMuICEC5i+w2/oqg4nX5PgvJ9hGjT305EbRGuI+wCIKYwbS3qoYUM ZBYqfJcMPbtdeaIGBFp63Vv0Yoq0w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpegrlhgvshhsrghnughrohgsrhhunhhirdhnrghmvgdpghhoohhglhgvrdgt ohhmpdhgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D451A7C412; Mon, 8 Apr 2019 19:17:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> Date: Mon, 08 Apr 2019 19:17:14 -0400 From: "Martin Thomson" To: secdispatch@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 23:17:50 -0000 Hi Roman, Ben, I=E2=80=99m a little surprised to see that your conclusion from the meet= ing we had was so clear. The summary shared at the end of the meeting hi= ghlighted the need to clarify the scope and nature of the requirements. = There has been some discussion on the list on this subject, but I haven=E2= =80=99t seen anything that indicates consensus around the problem statem= ent. The framing of this summary seems to imply that the goal is to work on E= DHOC. That seems premature. There seems to be agreement that the authe= nticated key exchange (AKE) protocols we have are inefficient in ways th= at affect these deployments. That doesn=E2=80=99t naturally imply that E= DHOC is a solution, only that there is a need to have an efficient AKE p= rotocol. =E2=80=9CAs cheap as possible=E2=80=9D is not a problem statement that i= s sufficiently precise to be acted upon. For example, the analysis for = LoRaWAN seemed to support the conclusion that ANY key exchange protocol = would fail badly, no matter how small, fast, or efficient. For deployme= nts with capabilities that might support an AKE, we have no grounds for = determining whether 5nJ or 1 octet difference is acceptable or not. Conc= rete objectives - ideally targets with numbers - are needed if we=E2=80=99= re to assess solutions. Even assuming that requirements are settled, I believe that there are co= nsiderations that go beyond the narrow definition of the problem stateme= nt. In the recent review of the T2TRG, I was reminded of their goal: > The Thing-to-Thing Research Group (T2TRG) will investigate open resear= ch issues in turning a true "Internet of Things" into reality, an Intern= et where low-resource nodes ("things", "constrained nodes") can communic= ate among themselves and with the wider Internet, in order to partake in= permissionless innovation. Though a little wordy, I think that this is a fine goal to keep in mind.= Deciding to create a working group specifically for EDHOC makes a dete= rmination directly in opposition to this goal. We=E2=80=99ve made simil= ar choices for application protocols like CoAP. For CoAP, the agreed fi= x was gateways and proxies. For a security protocol, that is not an opt= ion if you value end-to-end security. Cheers, Martin On Thu, Mar 28, 2019, at 21:33, Roman Danyliw wrote: > Hi! >=20 > We have observed the continued discussion and interest in the topics=20= > discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. =20= > Our assessment of the current state of this discuss and as well as=20 > proposed next steps are below. >=20 > Regards, > Roman and Ben >=20 > [1]=20 > https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4= ENZtrVk >=20 > =3D=3D[ Summary of ADs ]=3D=3D > EDHOC Summary >=20 > -----[ 1. What is the problem we are faced with? > =20 > The community needs an AKE that is 'lightweight' (per slide #3 of [2])= =20 > and enables forward security for constrained environments using OSCORE= =20 > [13]. 'Lightweight' refers to: > =20 > ** resource consumption, measured by bytes on the wire, wall-clock tim= e=20 > to complete (i.e., the initial latency added to application protocols=20= > by the AKE), or power (per slide #12 of [2]) > ** the amount of new code required on end systems which already have a= n=20 > OSCORE stack [4]=20 > =20 > -----[ 2. Is the problem understood and narrowly scoped? >=20 > Use with OSCORE implicitly assumes that this AKE would support: > ** transport over CoAP, and > ** COSE algorithms >=20 > The specific constrained environments that we are considering use=20 > NB-IoT, 6TiSCH, and LoRaWAN. The desire is to optimize the AKE to be=20= > 'as [small] ... as reasonably achievable' (per [3]) in these=20 > environments. >=20 > ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has= =20 > already identified the need to "secur[e] the join process and mak[e]=20= > that fit within the constraints of high latency, low throughput and=20= > small frame sizes that characterize IEEE802.15.4 TSCH." [12]. > ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG=20= > charter has identified the need to improve the transport capabilities=20= > of LPWA networks such as NB-IoT and LoRa whose "common traits include=20= > ... frame sizes ... [on] the order of tens of bytes transmitted a few=20= > times per day at ultra-low speeds" [16]. This indicates IETF interest=20= > in supporting these radio environments, though no security-specific=20= > requirements are included in the charter. > =20 > It may be necessary to evaluate options that make different trade-offs= =20 > across a number of dimensions. > =20 > ** Per 'bytes on the wire', it is desirable for these AKE messages to=20= > fit into the MTU size of these protocols; and if not possible, within=20= > as few frames as possible. Note that using multiple MTUs can have=20 > significant costs in terms of time and power (listed below). For 6TiSC= H=20 > specifically, as a time-sliced network, this metric (or rather, the=20= > quantization into frame count) is particularly noteworthy, since more=20= > frames contribute to congestion for spectrum (and concomitant error=20= > rates) in a non-linear way, especially in scenarios when large numbers= =20 > of independent nodes are attempting to execute an AKE to join a networ= k. > =20 > ** Per 'time', it is desirable for the AKE message exchange(s) to=20 > complete in a reasonable amount of time, both for a single uncongested= =20 > exchange and when multiple exchanges are running in an interleaved=20 > fashion. This latency may not be a linear function depending on=20 > congestion and the specific radio technology used. For LoRaWAN, which= =20 > is legally required to use a 1% (or smaller) duty cycle, a payload=20 > split into two fragments instead of one increases the time to complete= =20 > the sending of this payload by 10,000% (per slide #10 of [2]). =20 > =20 > ** Per 'power', it is desirable for the transmission of AKE messages=20= > and crypto to draw as little power as possible The best mechanism for= =20 > doing so differs across radio technologies. For example, NB-IoT uses=20= > licensed spectrum and thus can transmit at higher power to improve=20 > coverage, making the transmitted byte count relatively more important=20= > than for other radio technologies. In other cases, the radio=20 > transmitter will be active for a full MTU frame regardless of how much= =20 > of the frame is occupied by message content, which makes the byte coun= t=20 > less sensitive for the power consumption. Increased power consumption= =20 > is unavoidable in poor network conditions, such as most wide-area=20 > settings including LoRaWAN. >=20 > ** Per 'new code', it is desirable to introduce as little new code as=20= > possible onto OSCORE-enabled devices to support this new AKE. These=20= > devices have on the order of 10s of kB of memory and 100s of kB of=20 > storage on which an embedded OS; a COAP stack; CORE and AKE libraries;= =20 > and target applications would run. It is expected that the majority o= f=20 > this space is available for actual application logic, as opposed to=20= > the support libraries. >=20 > A key question to answer is whether any new solution will reduce these= =20 > properties to a sufficient extent to merit investment. > =20 > -----[ 3. Do we believe it is possible to engineer a solution? >=20 > EDHOC [1] appears to be an existence proof that it is possible to=20 > produce an AKE that meaningfully reduces the costs across at least two= =20 > dimensions identified in question #1 and 2 (bytes and time). =20 >=20 > EDHOC appears to favorably outperform TLS/CoAP, the current technology= ,=20 > relative to these dimensions.=20 > =20 > ** Per 'bytes on the wire', MTU sizes and their alignment to the size=20= > of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], an= d=20 > in [5]. Additional details for 6TiSCH in particular can be found in=20= > slide 36-37 of [2]. > =20 > ** Per 'time', the latency due to back-off time estimates with EDHOC=20= > vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2] > =20 > ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP usin= g=20 > NB-IoT can be found in slide #35 of [2]=20 > =20 > ** Per 'new code', being able to reuse primitives from the existing=20= > COSE stack is expected to benefit the code size for EDHOC, but no hard= =20 > data is yet available for comparison. =20 >=20 > Exploratory work with cTLS [10] and femtoTLS [11] has suggested that=20= > certain optimizations used in EDHOC can also be applied to a=20 > TLS/CoAP-variant. How this impacts the original assumptions and=20 > security analysis for (D)TLS is unknown.=20 > =20 > -----[ 4. Is this particular proposal a good basis for working on?=20 >=20 > EDHOC shows gains in defining an AKE with forward secrecy that is=20 > 'reasonably small[er]' than the baseline of (D)TLS. Specifically, it=20= > appears that EDHOC would enable: > ** for 6TiSCH, a more efficient network join operation, with network=20= > join traffic fitting in one frame per flight (that is, the optimal=20 > possible behavior) in up to a 5-hop network [17] > ** for LoRaWAN, an AKE with forward secrecy that avoids the=20 > unacceptable backoff-induced latency=20 >=20 > A limited interop was performed on draft-selander-ace-cose-ecdhe-05=20= > (EDHOC) at IETF 98 between [14] and [15]. Despite the inherent=20 > challenges of producing a new AKE that is secure, there is reason to=20= > have confidence in the security claims made by EDHOC -- the security=20= > properties of -08 were formally verified by [8][9]. Identified issues= =20 > from this formal analysis [8] were addressed in -11. The CFRG crypto=20= > review panel conducted two reviews [6][7]. These reviews confirmed=20= > that the security claims are reasonable, attested that the identified=20= > issues found in the formal analysis [8] were fixed, and provided=20 > additional recommendations. > =20 > Re-encoding of the TLS handshake as suggested by cTLS [10] may be=20 > possible. However, as of yet, cTLS is an incomplete specification,=20= > cTLS has no formal security analysis, and is technically a new protoco= l. >=20 > -----[ Conclusion >=20 > There appears to be an understood and scoped problem that is feasible=20= > to engineer. Among the available starting points to address the=20 > problem defined in question #1, EDHOC presents a viable choice. =20 >=20 > Chartering a narrowly scoped, short-lived WG in this space with EDHOC=20= > as a starting point seems to be an attractive path forward, but we=20 > would like to receive community feedback on the degree of support for=20= > this approach. >=20 > -----[ References > [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt > [2]=20 > https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/mater= ials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf > [3]=20 > https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdo= es4Y4lE > [4]=20 > https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril= -wIVn_0 > [5]=20 > https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbY= RNsMUlh-k > [6]=20 > https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8= > [7]=20 > https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ= > [8] https://alessandrobruni.name/papers/18-edhoc.pdf > [9] https://github.com/theisgroenbech/edhoc-proverif > [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 > [11] https://github.com/bifurcation/mint/compare/ftls > [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/ > [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/= > [14] https://github.com/alexkrontiris/EDHOC-C > [15] https://github.com/jimsch/EDHOC-csharp > [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/ > [17]=20 > https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouc= h-join >=20 > =3D=3D[ End ]=3D=3D >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > From nobody Tue Apr 9 00:23:55 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C0D1205FB for ; Tue, 9 Apr 2019 00:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_PERMERROR=0.01, 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 J_tsOfZH5jJP for ; Tue, 9 Apr 2019 00:23:51 -0700 (PDT) Received: from SELDSEGREL01.sonyericsson.com (seldsegrel01.sonyericsson.com [37.139.156.29]) (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 C6D1612037E for ; Tue, 9 Apr 2019 00:23:50 -0700 (PDT) From: "Blomqvist, Peter" To: Richard Barnes CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTuHNnZeJo8GkxQSjCOyScopZI0cQAFaXsAABuseP8= Date: Tue, 9 Apr 2019 07:23:47 +0000 Message-ID: <1554794627589.50834@sony.com> References: , In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.18.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 07:23:54 -0000 Hi Richard, Code footprint is not extremely constrained, typically Cortex M4 or similar= . Battery however is constrained. Also data transport. Optimistic marketing state that devices now can run 10 years on coin cells = - adding security to such a battery budget is problematic to say the least. 5G massive IoT will add severe constrains on data volumes. In such pessimistic scenarios data volumes could be limited to 200 bytes pe= r day, so a security overhead "as low as reasonably practicable" is critical. Best Peter ________________________________ Fr=E5n: Richard Barnes Skickat: den 8 april 2019 21:42 Till: Blomqvist, Peter Kopia: secdispatch@ietf.org =C4mne: Re: [Secdispatch] EDHOC Summary Hi Peter, I think a little more elaboration might be helpful :) What constraints are= these devices facing? E.g., in terms of transports, code footprint. Thanks, --Richard On Mon, Apr 8, 2019 at 11:23 AM Blomqvist, Peter > wrote: I was requested to elaborate on our use-cases for EDHOC: We believe that EDHOC & OSCORE enables lightweight key exchange and E2E se= curity for battery constrained devices running over cellular IoT ( NB-IoT and/or Cat M1) Best Peter _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch From nobody Tue Apr 9 01:43:27 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB091201DA for ; Tue, 9 Apr 2019 01:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPo6gu6Nt4in for ; Tue, 9 Apr 2019 01:43:13 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67568120794 for ; Tue, 9 Apr 2019 01:43:12 -0700 (PDT) Received: from client-0253.vpn.uni-bremen.de (client-0253.vpn.uni-bremen.de [134.102.107.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44dgmG1RSJzyYS; Tue, 9 Apr 2019 10:43:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <1554794627589.50834@sony.com> Date: Tue, 9 Apr 2019 10:43:09 +0200 Cc: Richard Barnes , "secdispatch@ietf.org" X-Mao-Original-Outgoing-Id: 576492187.548713-35335da4202fc20938fc49a8b954e8b0 Content-Transfer-Encoding: quoted-printable Message-Id: <2D4625E8-84C4-423C-8630-1C5FF6164B9F@tzi.org> References: <1554794627589.50834@sony.com> To: "Blomqvist, Peter" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 08:43:21 -0000 On Apr 9, 2019, at 09:23, Blomqvist, Peter = wrote: >=20 > 200 bytes per day Or 18.5 mbit/s (yes, millibits). Millibit networks is one of the scenarios where ALARA(*) as a design = objective does make sense =E2=80=94 there is no hard design limit, but = actual security will need to compete with less security, and ALARA helps = actual security stay competitive. Gr=C3=BC=C3=9Fe, Carsten (*) ALARA: =E2=80=9CAs low as reasonably achievable", a term stolen from = nuclear engineering. From nobody Tue Apr 9 04:58:00 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81E112078D for ; Tue, 9 Apr 2019 04:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 WFfxpb8-z01f for ; Tue, 9 Apr 2019 04:57:55 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00045.outbound.protection.outlook.com [40.107.0.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9BC12078B for ; Tue, 9 Apr 2019 04:57:54 -0700 (PDT) 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=xbhKNlav//aGXIhIzIkuSLjEi8bg987mw8SZ/fAr8nc=; b=Nlyop1RrmLIVA9EvbZ5+OCebJV/IO/bZ055aqtS9OmjnPbDRk6x8ltfUwuKAxTGdCqN5irB3vD3ZVnH5ywOdm+BTqt129BmHb6r+zY+6dn1zokx1KcF1GkwHlHFi7G2kiuXLuVcBxTDgIIZyNP6TFkJvfrLxyssD93q+bBm+p3o= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3241.eurprd07.prod.outlook.com (10.170.246.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Tue, 9 Apr 2019 11:57:52 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1792.007; Tue, 9 Apr 2019 11:57:52 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAJEpqUAAB7BU4A= Date: Tue, 9 Apr 2019 11:57:52 +0000 Message-ID: <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> In-Reply-To: <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7dfa1f29-0958-4945-cec2-08d6bce2985f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3241; x-ms-traffictypediagnostic: HE1PR07MB3241: x-ms-exchange-purlcount: 20 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(136003)(366004)(376002)(51444003)(199004)(189003)(78114003)(68736007)(186003)(2501003)(36756003)(33656002)(26005)(6506007)(11346002)(2616005)(446003)(486006)(305945005)(76176011)(102836004)(476003)(106356001)(105586002)(7736002)(6512007)(6306002)(53936002)(58126008)(6116002)(3846002)(6246003)(110136005)(6486002)(85202003)(2906002)(6436002)(316002)(410100003)(229853002)(561944003)(5660300002)(66066001)(99286004)(25786009)(30864003)(97736004)(83716004)(14454004)(86362001)(966005)(14444005)(71190400001)(71200400001)(256004)(8676002)(82746002)(81156014)(81166006)(478600001)(85182001)(66574012)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3241; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5q+v/+pNHfwL4rA4jgZ4311v0gt4uZ71+eWF8OLRvLMg5swLKJ6cKaWVEoMgzqUFM9gmH8Xviv3C+OQgYYj9XBPCdaAbgnMd9EYWh6Ib9R+uAISsp9uj68DxbUsYKo1aaGzvmdDXmo4iPARRnSB+kNcIoOqDYpSV2a+w9vgzOFzElShfMzyQxcW8pnD6dMrQxHv1H9KHXPcHKROAVQuRldvNl0x0YudKwBMYvL9Z5MHnE2GxEZjYr/3mKetup47NdAHy5C7knocVzu1c24GHyhIGGfoiKB2JLJ1m2EGqcs+6uniKin8JPfQ3OcxqI9SAuWx1KX4FIRSefh/jqPvQh00YGRLKg9Uia43LoPcI3DjaU+ZzhrmWcPXrN1kOuNrwX29gtl6kO0ED7huaeKvPYoydV0lZreqL0PouXhnLTF4= Content-Type: text/plain; charset="utf-8" Content-ID: <109F5BBC3190AC45B0E1C07E1E586032@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7dfa1f29-0958-4945-cec2-08d6bce2985f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 11:57:52.3569 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3241 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 11:57:59 -0000 SGkgTWFydGluLA0KDQpTb21lIGNvbW1lbnRzIGlubGluZS4NCg0K77u/T24gMjAxOS0wNC0wOSwg MDE6MTgsICJTZWNkaXNwYXRjaCBvbiBiZWhhbGYgb2YgTWFydGluIFRob21zb24iIDxzZWNkaXNw YXRjaC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtdEBsb3dlbnRyb3B5Lm5ldD4gd3Jv dGU6DQoNCiAgICBIaSBSb21hbiwgQmVuLA0KICAgIA0KICAgIEnigJltIGEgbGl0dGxlIHN1cnBy aXNlZCB0byBzZWUgdGhhdCB5b3VyIGNvbmNsdXNpb24gZnJvbSB0aGUgbWVldGluZyB3ZSBoYWQg d2FzIHNvIGNsZWFyLiBUaGUgc3VtbWFyeSBzaGFyZWQgYXQgdGhlIGVuZCBvZiB0aGUgbWVldGlu ZyBoaWdobGlnaHRlZCB0aGUgbmVlZCB0byBjbGFyaWZ5IHRoZSBzY29wZSBhbmQgbmF0dXJlIG9m IHRoZSByZXF1aXJlbWVudHMuIFRoZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUg bGlzdCBvbiB0aGlzIHN1YmplY3QsIGJ1dCBJIGhhdmVu4oCZdCBzZWVuIGFueXRoaW5nIHRoYXQg aW5kaWNhdGVzIGNvbnNlbnN1cyBhcm91bmQgdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0KDQpbR1Nd IFRoZXJlIHNlZW1zIHRvIGJlIGNvbnNlbnN1cyBvbiB0aGUgc3VtbWFyeSBwcm92aWRlZCBieSB0 aGUgU2VjdXJpdHkgQURzLCB3aGljaCBpbmNsdWRlcyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQoN CiAgICBUaGUgZnJhbWluZyBvZiB0aGlzIHN1bW1hcnkgc2VlbXMgdG8gaW1wbHkgdGhhdCB0aGUg Z29hbCBpcyB0byB3b3JrIG9uIEVESE9DLiAgVGhhdCBzZWVtcyBwcmVtYXR1cmUuICBUaGVyZSBz ZWVtcyB0byBiZSBhZ3JlZW1lbnQgdGhhdCB0aGUgYXV0aGVudGljYXRlZCBrZXkgZXhjaGFuZ2Ug KEFLRSkgcHJvdG9jb2xzIHdlIGhhdmUgYXJlIGluZWZmaWNpZW50IGluIHdheXMgdGhhdCBhZmZl Y3QgdGhlc2UgZGVwbG95bWVudHMuIFRoYXQgZG9lc27igJl0IG5hdHVyYWxseSBpbXBseSB0aGF0 IEVESE9DIGlzIGEgc29sdXRpb24sIG9ubHkgdGhhdCB0aGVyZSBpcyBhIG5lZWQgdG8gaGF2ZSBh biBlZmZpY2llbnQgQUtFIHByb3RvY29sLg0KDQpbR1NdIFRoZXJlIGlzIG5vIGNvbXBldGluZyBz b2x1dGlvbiB0byB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuIEFzIGJlZW4gd2l0bmVzc2VkLCBwZW9w bGUgaGF2ZSB3YWl0ZWQgZm9yIHllYXJzIGZvciB0aGlzIHRvIHByb2dyZXNzLiBUaGVyZWZvcmUg SSBkb24ndCBzZWUgYW55dGhpbmcgcHJlbWF0dXJlIHdpdGggYXNzdW1pbmcgRURIT0MgdG8gYmUg YSBzdGFydGluZyBwb2ludCBmb3IgdGhlIFdHLiANCg0KICAgIOKAnEFzIGNoZWFwIGFzIHBvc3Np Ymxl4oCdIGlzIG5vdCBhIHByb2JsZW0gc3RhdGVtZW50IHRoYXQgaXMgc3VmZmljaWVudGx5IHBy ZWNpc2UgdG8gYmUgYWN0ZWQgdXBvbi4gIEZvciBleGFtcGxlLCB0aGUgYW5hbHlzaXMgZm9yIExv UmFXQU4gc2VlbWVkIHRvIHN1cHBvcnQgdGhlIGNvbmNsdXNpb24gdGhhdCBBTlkga2V5IGV4Y2hh bmdlIHByb3RvY29sIHdvdWxkIGZhaWwgYmFkbHksIG5vIG1hdHRlciBob3cgc21hbGwsIGZhc3Qs IG9yIGVmZmljaWVudC4gIEZvciBkZXBsb3ltZW50cyB3aXRoIGNhcGFiaWxpdGllcyB0aGF0IG1p Z2h0IHN1cHBvcnQgYW4gQUtFLCB3ZSBoYXZlIG5vIGdyb3VuZHMgZm9yIGRldGVybWluaW5nIHdo ZXRoZXIgNW5KIG9yIDEgb2N0ZXQgZGlmZmVyZW5jZSBpcyBhY2NlcHRhYmxlIG9yIG5vdC4gQ29u Y3JldGUgb2JqZWN0aXZlcyAtIGlkZWFsbHkgdGFyZ2V0cyB3aXRoIG51bWJlcnMgLSBhcmUgbmVl ZGVkIGlmIHdl4oCZcmUgdG8gYXNzZXNzIHNvbHV0aW9ucy4NCiAgIA0KW0dTXSBDb25jcmV0ZSB0 YXJnZXRzIHdpdGggbnVtYmVycyBoYXZlIGJlZW4gcHJlc2VudGVkLCBmb3IgZXhhbXBsZSBoZXJl Og0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC92TlI3 blQyMGZzdllqWVhoQVBqT3BMalpHQ1UNCg0KICAgIEV2ZW4gYXNzdW1pbmcgdGhhdCByZXF1aXJl bWVudHMgYXJlIHNldHRsZWQsIEkgYmVsaWV2ZSB0aGF0IHRoZXJlIGFyZSBjb25zaWRlcmF0aW9u cyB0aGF0IGdvIGJleW9uZCB0aGUgbmFycm93IGRlZmluaXRpb24gb2YgdGhlIHByb2JsZW0gc3Rh dGVtZW50LiBJbiB0aGUgcmVjZW50IHJldmlldyBvZiB0aGUgVDJUUkcsIEkgd2FzIHJlbWluZGVk IG9mIHRoZWlyIGdvYWw6DQogICAgDQogICAgPiBUaGUgVGhpbmctdG8tVGhpbmcgUmVzZWFyY2gg R3JvdXAgKFQyVFJHKSB3aWxsIGludmVzdGlnYXRlIG9wZW4gcmVzZWFyY2ggaXNzdWVzIGluIHR1 cm5pbmcgYSB0cnVlICJJbnRlcm5ldCBvZiBUaGluZ3MiIGludG8gcmVhbGl0eSwgYW4gSW50ZXJu ZXQgd2hlcmUgbG93LXJlc291cmNlIG5vZGVzICgidGhpbmdzIiwgImNvbnN0cmFpbmVkIG5vZGVz IikgY2FuIGNvbW11bmljYXRlIGFtb25nIHRoZW1zZWx2ZXMgYW5kIHdpdGggdGhlIHdpZGVyIElu dGVybmV0LCBpbiBvcmRlciB0byBwYXJ0YWtlIGluIHBlcm1pc3Npb25sZXNzIGlubm92YXRpb24u DQogICAgDQogICAgVGhvdWdoIGEgbGl0dGxlIHdvcmR5LCBJIHRoaW5rIHRoYXQgdGhpcyBpcyBh IGZpbmUgZ29hbCB0byBrZWVwIGluIG1pbmQuICBEZWNpZGluZyB0byBjcmVhdGUgYSB3b3JraW5n IGdyb3VwIHNwZWNpZmljYWxseSBmb3IgRURIT0MgbWFrZXMgYSBkZXRlcm1pbmF0aW9uIGRpcmVj dGx5IGluIG9wcG9zaXRpb24gdG8gdGhpcyBnb2FsLiAgV2XigJl2ZSBtYWRlIHNpbWlsYXIgY2hv aWNlcyBmb3IgYXBwbGljYXRpb24gcHJvdG9jb2xzIGxpa2UgQ29BUC4gIEZvciBDb0FQLCB0aGUg YWdyZWVkIGZpeCB3YXMgZ2F0ZXdheXMgYW5kIHByb3hpZXMuICBGb3IgYSBzZWN1cml0eSBwcm90 b2NvbCwgdGhhdCBpcyBub3QgYW4gb3B0aW9uIGlmIHlvdSB2YWx1ZSBlbmQtdG8tZW5kIHNlY3Vy aXR5Lg0KICAgDQpbR1NdIEEgbGlnaHR3ZWlnaHQgQUtFIG9uIGFwcGxpY2F0aW9uIGxheWVyLCB3 aGljaCB0aGlzIHNwZWNpZmljIFdHIGlzIHByb3Bvc2VkIHRvIHdvcmsgb24sIGlzIGFjdHVhbGx5 IGEgbWlzc2luZyBlbmFibGVyIGZvciBjb25zdHJhaW5lZCBub2RlcyB0byAgImNvbW11bmljYXRl IGFtb25nIHRoZW1zZWx2ZXMgYW5kIHdpdGggdGhlIHdpZGVyIEludGVybmV0Ii4gSW5kZWVkLCBp ZiB0aGUgc2VjdXJpdHkgcHJvdG9jb2wgaXMgdG9vIGhlYXZ5IG9yIG5lZWRzIHRvIHRlcm1pbmF0 ZSBpbiBhIGdhdGV3YXkgZHVlIHRvIGNoYW5nZSBvZiB0cmFuc3BvcnQgZXRjLiwgdGhlbiBlbmQt dG8tZW5kIHNlY3VyZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGVuZHBvaW50cyB3aWxsIG5v dCB0YWtlIHBsYWNlLCB0aHVzIHByZXZlbnRpbmcgInRvIHBhcnRha2UgaW4gcGVybWlzc2lvbmxl c3MgaW5ub3ZhdGlvbiIuICANCg0KR8O2cmFuDQoNCg0KDQogICAgQ2hlZXJzLA0KICAgIE1hcnRp bg0KICAgIA0KICAgIE9uIFRodSwgTWFyIDI4LCAyMDE5LCBhdCAyMTozMywgUm9tYW4gRGFueWxp dyB3cm90ZToNCiAgICA+IEhpIQ0KICAgID4gDQogICAgPiBXZSBoYXZlIG9ic2VydmVkIHRoZSBj b250aW51ZWQgZGlzY3Vzc2lvbiBhbmQgaW50ZXJlc3QgaW4gdGhlIHRvcGljcyANCiAgICA+IGRp c2N1c3NlZCBhdCB0aGUgTWFyY2ggMjAxOSBWaXJ0dWFsIEludGVyaW0gU2VjZGlzcGF0Y2ggbWVl dGluZyBbMV0uICANCiAgICA+IE91ciBhc3Nlc3NtZW50IG9mIHRoZSBjdXJyZW50IHN0YXRlIG9m IHRoaXMgZGlzY3VzcyBhbmQgYXMgd2VsbCBhcyANCiAgICA+IHByb3Bvc2VkIG5leHQgc3RlcHMg YXJlIGJlbG93Lg0KICAgID4gDQogICAgPiBSZWdhcmRzLA0KICAgID4gUm9tYW4gYW5kIEJlbg0K ICAgID4gDQogICAgPiBbMV0gDQogICAgPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NlY2Rpc3BhdGNoLzlBZnFyZWNaZkZNbE1HeFNYT280RU5adHJWaw0KICAgID4gDQog ICAgPiA9PVsgU3VtbWFyeSBvZiBBRHMgXT09DQogICAgPiBFREhPQyBTdW1tYXJ5DQogICAgPiAN CiAgICA+IC0tLS0tWyAxLiBXaGF0IGlzIHRoZSBwcm9ibGVtIHdlIGFyZSBmYWNlZCB3aXRoPw0K ICAgID4gIA0KICAgID4gVGhlIGNvbW11bml0eSBuZWVkcyBhbiBBS0UgdGhhdCBpcyAnbGlnaHR3 ZWlnaHQnIChwZXIgc2xpZGUgIzMgb2YgWzJdKSANCiAgICA+IGFuZCBlbmFibGVzIGZvcndhcmQg c2VjdXJpdHkgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyB1c2luZyBPU0NPUkUgDQogICAg PiBbMTNdLiAgJ0xpZ2h0d2VpZ2h0JyByZWZlcnMgdG86DQogICAgPiAgDQogICAgPiAqKiByZXNv dXJjZSBjb25zdW1wdGlvbiwgbWVhc3VyZWQgYnkgYnl0ZXMgb24gdGhlIHdpcmUsIHdhbGwtY2xv Y2sgdGltZSANCiAgICA+IHRvIGNvbXBsZXRlIChpLmUuLCB0aGUgaW5pdGlhbCBsYXRlbmN5IGFk ZGVkIHRvIGFwcGxpY2F0aW9uIHByb3RvY29scyANCiAgICA+IGJ5IHRoZSBBS0UpLCBvciBwb3dl ciAocGVyIHNsaWRlICMxMiBvZiBbMl0pDQogICAgPiAqKiB0aGUgYW1vdW50IG9mIG5ldyBjb2Rl IHJlcXVpcmVkIG9uIGVuZCBzeXN0ZW1zIHdoaWNoIGFscmVhZHkgaGF2ZSBhbiANCiAgICA+IE9T Q09SRSBzdGFjayBbNF0gDQogICAgPiAgDQogICAgPiAtLS0tLVsgMi4gSXMgdGhlIHByb2JsZW0g dW5kZXJzdG9vZCBhbmQgbmFycm93bHkgc2NvcGVkPw0KICAgID4gDQogICAgPiBVc2Ugd2l0aCBP U0NPUkUgaW1wbGljaXRseSBhc3N1bWVzIHRoYXQgdGhpcyBBS0Ugd291bGQgc3VwcG9ydDoNCiAg ICA+ICoqIHRyYW5zcG9ydCBvdmVyIENvQVAsIGFuZA0KICAgID4gKiogQ09TRSBhbGdvcml0aG1z DQogICAgPiANCiAgICA+IFRoZSBzcGVjaWZpYyBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgdGhh dCB3ZSBhcmUgY29uc2lkZXJpbmcgdXNlIA0KICAgID4gTkItSW9ULCA2VGlTQ0gsIGFuZCBMb1Jh V0FOLiAgVGhlIGRlc2lyZSBpcyB0byBvcHRpbWl6ZSB0aGUgQUtFIHRvIGJlIA0KICAgID4gJ2Fz IFtzbWFsbF0gLi4uIGFzIHJlYXNvbmFibHkgYWNoaWV2YWJsZScgKHBlciBbM10pIGluIHRoZXNl IA0KICAgID4gZW52aXJvbm1lbnRzLg0KICAgID4gDQogICAgPiAqKiBXaXRoIHJlc3BlY3QgdG8g NlRpU0NILCBJRVRGIGNvbnNlbnN1cyBvbiB0aGUgNlRpU0NIIFdHIGNoYXJ0ZXIgaGFzIA0KICAg ID4gYWxyZWFkeSBpZGVudGlmaWVkIHRoZSBuZWVkIHRvICJzZWN1cltlXSB0aGUgam9pbiBwcm9j ZXNzIGFuZCBtYWtbZV0gDQogICAgPiB0aGF0IGZpdCB3aXRoaW4gdGhlIGNvbnN0cmFpbnRzIG9m IGhpZ2ggbGF0ZW5jeSwgbG93IHRocm91Z2hwdXQgYW5kIA0KICAgID4gc21hbGwgZnJhbWUgc2l6 ZXMgdGhhdCBjaGFyYWN0ZXJpemUgSUVFRTgwMi4xNS40IFRTQ0guIiBbMTJdLg0KICAgID4gKiog V2l0aCByZXNwZWN0IHRvIE5CLUlvVCBhbmQgTG9SYVdBTiwgSUVURiBjb25zZW5zdXMgb24gdGhl IExQV0FOIFdHIA0KICAgID4gY2hhcnRlciBoYXMgaWRlbnRpZmllZCB0aGUgbmVlZCB0byBpbXBy b3ZlIHRoZSB0cmFuc3BvcnQgY2FwYWJpbGl0aWVzIA0KICAgID4gb2YgTFBXQSBuZXR3b3JrcyBz dWNoIGFzIE5CLUlvVCBhbmQgTG9SYSB3aG9zZSAiY29tbW9uIHRyYWl0cyBpbmNsdWRlIA0KICAg ID4gLi4uIGZyYW1lIHNpemVzIC4uLiBbb25dIHRoZSBvcmRlciBvZiB0ZW5zIG9mIGJ5dGVzIHRy YW5zbWl0dGVkIGEgZmV3IA0KICAgID4gdGltZXMgcGVyIGRheSBhdCB1bHRyYS1sb3cgc3BlZWRz IiBbMTZdLiBUaGlzIGluZGljYXRlcyBJRVRGIGludGVyZXN0IA0KICAgID4gaW4gc3VwcG9ydGlu ZyB0aGVzZSByYWRpbyBlbnZpcm9ubWVudHMsIHRob3VnaCBubyBzZWN1cml0eS1zcGVjaWZpYyAN CiAgICA+IHJlcXVpcmVtZW50cyBhcmUgaW5jbHVkZWQgaW4gdGhlIGNoYXJ0ZXIuDQogICAgPiAg DQogICAgPiBJdCBtYXkgYmUgbmVjZXNzYXJ5IHRvIGV2YWx1YXRlIG9wdGlvbnMgdGhhdCBtYWtl IGRpZmZlcmVudCB0cmFkZS1vZmZzIA0KICAgID4gYWNyb3NzIGEgbnVtYmVyIG9mIGRpbWVuc2lv bnMuDQogICAgPiAgDQogICAgPiAqKiBQZXIgJ2J5dGVzIG9uIHRoZSB3aXJlJywgaXQgaXMgZGVz aXJhYmxlIGZvciB0aGVzZSBBS0UgbWVzc2FnZXMgdG8gDQogICAgPiBmaXQgaW50byB0aGUgTVRV IHNpemUgb2YgdGhlc2UgcHJvdG9jb2xzOyBhbmQgaWYgbm90IHBvc3NpYmxlLCB3aXRoaW4gDQog ICAgPiBhcyBmZXcgZnJhbWVzIGFzIHBvc3NpYmxlLiAgTm90ZSB0aGF0IHVzaW5nIG11bHRpcGxl IE1UVXMgY2FuIGhhdmUgDQogICAgPiBzaWduaWZpY2FudCBjb3N0cyBpbiB0ZXJtcyBvZiB0aW1l IGFuZCBwb3dlciAobGlzdGVkIGJlbG93KS4gRm9yIDZUaVNDSCANCiAgICA+IHNwZWNpZmljYWxs eSwgYXMgYSB0aW1lLXNsaWNlZCBuZXR3b3JrLCB0aGlzIG1ldHJpYyAob3IgcmF0aGVyLCB0aGUg DQogICAgPiBxdWFudGl6YXRpb24gaW50byBmcmFtZSBjb3VudCkgaXMgcGFydGljdWxhcmx5IG5v dGV3b3J0aHksIHNpbmNlIG1vcmUgDQogICAgPiBmcmFtZXMgY29udHJpYnV0ZSAgdG8gY29uZ2Vz dGlvbiBmb3Igc3BlY3RydW0gKGFuZCBjb25jb21pdGFudCBlcnJvciANCiAgICA+IHJhdGVzKSBp biBhIG5vbi1saW5lYXIgd2F5LCBlc3BlY2lhbGx5IGluIHNjZW5hcmlvcyB3aGVuIGxhcmdlIG51 bWJlcnMgDQogICAgPiBvZiBpbmRlcGVuZGVudCBub2RlcyBhcmUgYXR0ZW1wdGluZyB0byBleGVj dXRlIGFuIEFLRSB0byBqb2luIGEgbmV0d29yay4NCiAgICA+ICANCiAgICA+ICoqIFBlciAndGlt ZScsIGl0IGlzIGRlc2lyYWJsZSBmb3IgdGhlIEFLRSBtZXNzYWdlIGV4Y2hhbmdlKHMpIHRvIA0K ICAgID4gY29tcGxldGUgaW4gYSByZWFzb25hYmxlIGFtb3VudCBvZiB0aW1lLCBib3RoIGZvciBh IHNpbmdsZSB1bmNvbmdlc3RlZCANCiAgICA+IGV4Y2hhbmdlIGFuZCB3aGVuIG11bHRpcGxlIGV4 Y2hhbmdlcyBhcmUgcnVubmluZyBpbiBhbiBpbnRlcmxlYXZlZCANCiAgICA+IGZhc2hpb24uICBU aGlzIGxhdGVuY3kgbWF5IG5vdCBiZSBhIGxpbmVhciBmdW5jdGlvbiBkZXBlbmRpbmcgb24gDQog ICAgPiBjb25nZXN0aW9uIGFuZCB0aGUgc3BlY2lmaWMgcmFkaW8gdGVjaG5vbG9neSB1c2VkLiAg Rm9yIExvUmFXQU4sIHdoaWNoIA0KICAgID4gaXMgbGVnYWxseSByZXF1aXJlZCB0byB1c2UgYSAx JSAob3Igc21hbGxlcikgZHV0eSBjeWNsZSwgYSBwYXlsb2FkIA0KICAgID4gc3BsaXQgaW50byB0 d28gZnJhZ21lbnRzIGluc3RlYWQgb2Ygb25lIGluY3JlYXNlcyB0aGUgdGltZSB0byBjb21wbGV0 ZSANCiAgICA+IHRoZSBzZW5kaW5nIG9mIHRoaXMgcGF5bG9hZCBieSAxMCwwMDAlIChwZXIgc2xp ZGUgIzEwIG9mIFsyXSkuICANCiAgICA+ICANCiAgICA+ICoqIFBlciAncG93ZXInLCBpdCBpcyBk ZXNpcmFibGUgZm9yIHRoZSB0cmFuc21pc3Npb24gb2YgQUtFIG1lc3NhZ2VzIA0KICAgID4gYW5k IGNyeXB0byB0byBkcmF3IGFzIGxpdHRsZSBwb3dlciBhcyBwb3NzaWJsZSAgVGhlIGJlc3QgbWVj aGFuaXNtIGZvciANCiAgICA+IGRvaW5nIHNvIGRpZmZlcnMgYWNyb3NzIHJhZGlvIHRlY2hub2xv Z2llcy4gIEZvciBleGFtcGxlLCBOQi1Jb1QgdXNlcyANCiAgICA+IGxpY2Vuc2VkIHNwZWN0cnVt IGFuZCB0aHVzIGNhbiB0cmFuc21pdCBhdCBoaWdoZXIgcG93ZXIgdG8gaW1wcm92ZSANCiAgICA+ IGNvdmVyYWdlLCBtYWtpbmcgdGhlIHRyYW5zbWl0dGVkIGJ5dGUgY291bnQgcmVsYXRpdmVseSBt b3JlIGltcG9ydGFudCANCiAgICA+IHRoYW4gZm9yIG90aGVyIHJhZGlvIHRlY2hub2xvZ2llcy4g IEluIG90aGVyIGNhc2VzLCB0aGUgcmFkaW8gDQogICAgPiB0cmFuc21pdHRlciB3aWxsIGJlIGFj dGl2ZSBmb3IgYSBmdWxsIE1UVSBmcmFtZSByZWdhcmRsZXNzIG9mIGhvdyBtdWNoIA0KICAgID4g b2YgdGhlIGZyYW1lIGlzIG9jY3VwaWVkIGJ5IG1lc3NhZ2UgY29udGVudCwgd2hpY2ggbWFrZXMg dGhlIGJ5dGUgY291bnQgDQogICAgPiBsZXNzIHNlbnNpdGl2ZSBmb3IgdGhlIHBvd2VyIGNvbnN1 bXB0aW9uLiAgSW5jcmVhc2VkIHBvd2VyIGNvbnN1bXB0aW9uIA0KICAgID4gaXMgdW5hdm9pZGFi bGUgaW4gcG9vciBuZXR3b3JrIGNvbmRpdGlvbnMsIHN1Y2ggYXMgbW9zdCB3aWRlLWFyZWEgDQog ICAgPiBzZXR0aW5ncyBpbmNsdWRpbmcgTG9SYVdBTi4NCiAgICA+IA0KICAgID4gKiogUGVyICdu ZXcgY29kZScsIGl0IGlzIGRlc2lyYWJsZSB0byBpbnRyb2R1Y2UgYXMgbGl0dGxlIG5ldyBjb2Rl IGFzIA0KICAgID4gcG9zc2libGUgb250byBPU0NPUkUtZW5hYmxlZCBkZXZpY2VzIHRvIHN1cHBv cnQgdGhpcyBuZXcgQUtFLiAgVGhlc2UgDQogICAgPiBkZXZpY2VzIGhhdmUgb24gdGhlIG9yZGVy IG9mIDEwcyBvZiBrQiBvZiBtZW1vcnkgYW5kIDEwMHMgb2Yga0Igb2YgDQogICAgPiBzdG9yYWdl IG9uIHdoaWNoIGFuIGVtYmVkZGVkIE9TOyBhIENPQVAgc3RhY2s7IENPUkUgYW5kIEFLRSBsaWJy YXJpZXM7IA0KICAgID4gYW5kIHRhcmdldCBhcHBsaWNhdGlvbnMgd291bGQgcnVuLiAgSXQgaXMg ZXhwZWN0ZWQgdGhhdCB0aGUgbWFqb3JpdHkgb2YgDQogICAgPiB0aGlzIHNwYWNlIGlzICBhdmFp bGFibGUgZm9yIGFjdHVhbCBhcHBsaWNhdGlvbiBsb2dpYywgYXMgb3Bwb3NlZCB0byANCiAgICA+ IHRoZSBzdXBwb3J0IGxpYnJhcmllcy4NCiAgICA+IA0KICAgID4gQSBrZXkgcXVlc3Rpb24gdG8g YW5zd2VyIGlzIHdoZXRoZXIgYW55IG5ldyBzb2x1dGlvbiB3aWxsIHJlZHVjZSB0aGVzZSANCiAg ICA+IHByb3BlcnRpZXMgdG8gYSBzdWZmaWNpZW50IGV4dGVudCB0byBtZXJpdCBpbnZlc3RtZW50 Lg0KICAgID4gIA0KICAgID4gLS0tLS1bIDMuIERvIHdlIGJlbGlldmUgaXQgaXMgcG9zc2libGUg dG8gZW5naW5lZXIgYSBzb2x1dGlvbj8NCiAgICA+IA0KICAgID4gRURIT0MgWzFdIGFwcGVhcnMg dG8gYmUgYW4gZXhpc3RlbmNlIHByb29mIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gDQogICAgPiBw cm9kdWNlIGFuIEFLRSB0aGF0IG1lYW5pbmdmdWxseSByZWR1Y2VzIHRoZSBjb3N0cyBhY3Jvc3Mg YXQgbGVhc3QgdHdvIA0KICAgID4gZGltZW5zaW9ucyBpZGVudGlmaWVkIGluIHF1ZXN0aW9uICMx IGFuZCAyIChieXRlcyBhbmQgdGltZSkuICANCiAgICA+IA0KICAgID4gRURIT0MgYXBwZWFycyB0 byBmYXZvcmFibHkgb3V0cGVyZm9ybSBUTFMvQ29BUCwgdGhlIGN1cnJlbnQgdGVjaG5vbG9neSwg DQogICAgPiByZWxhdGl2ZSB0byB0aGVzZSBkaW1lbnNpb25zLiANCiAgICA+ICANCiAgICA+ICoq IFBlciAnYnl0ZXMgb24gdGhlIHdpcmUnLCBNVFUgc2l6ZXMgYW5kIHRoZWlyIGFsaWdubWVudCB0 byB0aGUgc2l6ZSANCiAgICA+IG9mIG1lc3NhZ2VzIG9mIEVESE9DIHZzLiBUTFMvQ29BUCBjYW4g YmUgZm91bmQgaW4gc2xpZGUgIzMzIG9mIFsyXSwgYW5kIA0KICAgID4gaW4gWzVdLiAgQWRkaXRp b25hbCBkZXRhaWxzIGZvciA2VGlTQ0ggaW4gcGFydGljdWxhciBjYW4gYmUgZm91bmQgaW4gDQog ICAgPiBzbGlkZSAzNi0zNyBvZiBbMl0uDQogICAgPiAgDQogICAgPiAqKiBQZXIgJ3RpbWUnLCB0 aGUgbGF0ZW5jeSBkdWUgdG8gYmFjay1vZmYgdGltZSBlc3RpbWF0ZXMgd2l0aCBFREhPQyANCiAg ICA+IHZzLiBUTFMvQ29BUCB1c2luZyBMb1JhV0FOIGNhbiBiZSBmb3VuZCBpbiBzbGlkZSAjMzkg b2YgWzJdDQogICAgPiAgDQogICAgPiAqKiBQZXIgJ3Bvd2VyJywgZXN0aW1hdGVzIG9mIHRoZSBw b3dlciB1c2FnZSBvZiBFREhPQyB2cyBUTFMvQ29BUCB1c2luZyANCiAgICA+IE5CLUlvVCBjYW4g YmUgZm91bmQgaW4gc2xpZGUgIzM1IG9mIFsyXSANCiAgICA+ICANCiAgICA+ICoqIFBlciAnbmV3 IGNvZGUnLCBiZWluZyBhYmxlIHRvIHJldXNlIHByaW1pdGl2ZXMgZnJvbSB0aGUgZXhpc3Rpbmcg DQogICAgPiBDT1NFIHN0YWNrIGlzIGV4cGVjdGVkIHRvIGJlbmVmaXQgdGhlIGNvZGUgc2l6ZSBm b3IgRURIT0MsIGJ1dCBubyBoYXJkIA0KICAgID4gZGF0YSBpcyB5ZXQgYXZhaWxhYmxlIGZvciBj b21wYXJpc29uLiAgDQogICAgPiANCiAgICA+IEV4cGxvcmF0b3J5IHdvcmsgd2l0aCBjVExTIFsx MF0gYW5kIGZlbXRvVExTIFsxMV0gaGFzIHN1Z2dlc3RlZCB0aGF0IA0KICAgID4gY2VydGFpbiBv cHRpbWl6YXRpb25zIHVzZWQgaW4gRURIT0MgY2FuIGFsc28gYmUgYXBwbGllZCB0byBhIA0KICAg ID4gVExTL0NvQVAtdmFyaWFudC4gIEhvdyB0aGlzIGltcGFjdHMgdGhlIG9yaWdpbmFsIGFzc3Vt cHRpb25zIGFuZCANCiAgICA+IHNlY3VyaXR5IGFuYWx5c2lzIGZvciAoRClUTFMgaXMgdW5rbm93 bi4gDQogICAgPiAgDQogICAgPiAtLS0tLVsgNC4gSXMgdGhpcyBwYXJ0aWN1bGFyIHByb3Bvc2Fs IGEgZ29vZCBiYXNpcyBmb3Igd29ya2luZyBvbj8gDQogICAgPiANCiAgICA+IEVESE9DIHNob3dz IGdhaW5zIGluIGRlZmluaW5nIGFuIEFLRSB3aXRoIGZvcndhcmQgc2VjcmVjeSB0aGF0IGlzIA0K ICAgID4gJ3JlYXNvbmFibHkgc21hbGxbZXJdJyB0aGFuIHRoZSBiYXNlbGluZSBvZiAoRClUTFMu ICBTcGVjaWZpY2FsbHksIGl0IA0KICAgID4gYXBwZWFycyB0aGF0IEVESE9DIHdvdWxkIGVuYWJs ZToNCiAgICA+ICoqIGZvciA2VGlTQ0gsIGEgbW9yZSBlZmZpY2llbnQgbmV0d29yayBqb2luIG9w ZXJhdGlvbiwgd2l0aCBuZXR3b3JrIA0KICAgID4gam9pbiB0cmFmZmljIGZpdHRpbmcgaW4gb25l IGZyYW1lIHBlciBmbGlnaHQgKHRoYXQgaXMsIHRoZSBvcHRpbWFsIA0KICAgID4gcG9zc2libGUg YmVoYXZpb3IpIGluIHVwIHRvIGEgNS1ob3AgbmV0d29yayBbMTddDQogICAgPiAqKiBmb3IgTG9S YVdBTiwgYW4gQUtFIHdpdGggZm9yd2FyZCBzZWNyZWN5IHRoYXQgYXZvaWRzIHRoZSANCiAgICA+ IHVuYWNjZXB0YWJsZSBiYWNrb2ZmLWluZHVjZWQgbGF0ZW5jeSANCiAgICA+IA0KICAgID4gQSBs aW1pdGVkIGludGVyb3Agd2FzIHBlcmZvcm1lZCBvbiBkcmFmdC1zZWxhbmRlci1hY2UtY29zZS1l Y2RoZS0wNSANCiAgICA+IChFREhPQykgYXQgSUVURiA5OCBiZXR3ZWVuIFsxNF0gYW5kIFsxNV0u ICBEZXNwaXRlIHRoZSBpbmhlcmVudCANCiAgICA+IGNoYWxsZW5nZXMgb2YgcHJvZHVjaW5nIGEg bmV3IEFLRSB0aGF0IGlzIHNlY3VyZSwgdGhlcmUgaXMgcmVhc29uIHRvIA0KICAgID4gaGF2ZSBj b25maWRlbmNlIGluIHRoZSBzZWN1cml0eSBjbGFpbXMgbWFkZSBieSBFREhPQyAtLSB0aGUgc2Vj dXJpdHkgDQogICAgPiBwcm9wZXJ0aWVzIG9mIC0wOCB3ZXJlIGZvcm1hbGx5IHZlcmlmaWVkIGJ5 IFs4XVs5XS4gIElkZW50aWZpZWQgaXNzdWVzIA0KICAgID4gZnJvbSB0aGlzIGZvcm1hbCBhbmFs eXNpcyBbOF0gd2VyZSBhZGRyZXNzZWQgaW4gLTExLiAgVGhlIENGUkcgY3J5cHRvIA0KICAgID4g cmV2aWV3IHBhbmVsIGNvbmR1Y3RlZCB0d28gcmV2aWV3cyBbNl1bN10uICBUaGVzZSByZXZpZXdz IGNvbmZpcm1lZCANCiAgICA+IHRoYXQgdGhlIHNlY3VyaXR5IGNsYWltcyBhcmUgcmVhc29uYWJs ZSwgYXR0ZXN0ZWQgdGhhdCB0aGUgaWRlbnRpZmllZCANCiAgICA+IGlzc3VlcyBmb3VuZCBpbiB0 aGUgZm9ybWFsIGFuYWx5c2lzIFs4XSB3ZXJlIGZpeGVkLCBhbmQgcHJvdmlkZWQgDQogICAgPiBh ZGRpdGlvbmFsIHJlY29tbWVuZGF0aW9ucy4NCiAgICA+ICANCiAgICA+IFJlLWVuY29kaW5nIG9m IHRoZSBUTFMgaGFuZHNoYWtlIGFzIHN1Z2dlc3RlZCBieSBjVExTIFsxMF0gbWF5IGJlIA0KICAg ID4gcG9zc2libGUuICBIb3dldmVyLCBhcyBvZiB5ZXQsIGNUTFMgaXMgYW4gaW5jb21wbGV0ZSBz cGVjaWZpY2F0aW9uLCANCiAgICA+IGNUTFMgaGFzIG5vIGZvcm1hbCBzZWN1cml0eSBhbmFseXNp cywgYW5kIGlzIHRlY2huaWNhbGx5IGEgbmV3IHByb3RvY29sLg0KICAgID4gDQogICAgPiAtLS0t LVsgQ29uY2x1c2lvbg0KICAgID4gDQogICAgPiBUaGVyZSBhcHBlYXJzIHRvIGJlIGFuIHVuZGVy c3Rvb2QgYW5kIHNjb3BlZCBwcm9ibGVtIHRoYXQgaXMgZmVhc2libGUgDQogICAgPiB0byBlbmdp bmVlci4gIEFtb25nIHRoZSBhdmFpbGFibGUgc3RhcnRpbmcgcG9pbnRzIHRvIGFkZHJlc3MgdGhl IA0KICAgID4gcHJvYmxlbSBkZWZpbmVkIGluIHF1ZXN0aW9uICMxLCBFREhPQyBwcmVzZW50cyBh IHZpYWJsZSBjaG9pY2UuICANCiAgICA+IA0KICAgID4gQ2hhcnRlcmluZyBhIG5hcnJvd2x5IHNj b3BlZCwgc2hvcnQtbGl2ZWQgV0cgaW4gdGhpcyBzcGFjZSB3aXRoIEVESE9DIA0KICAgID4gYXMg YSBzdGFydGluZyBwb2ludCBzZWVtcyB0byBiZSBhbiBhdHRyYWN0aXZlIHBhdGggZm9yd2FyZCwg YnV0IHdlIA0KICAgID4gd291bGQgbGlrZSB0byByZWNlaXZlIGNvbW11bml0eSBmZWVkYmFjayBv biB0aGUgZGVncmVlIG9mIHN1cHBvcnQgZm9yIA0KICAgID4gdGhpcyBhcHByb2FjaC4NCiAgICA+ IA0KICAgID4gLS0tLS1bIFJlZmVyZW5jZXMNCiAgICA+IFsxXSBodHRwczovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS0xMy50eHQNCiAgICA+IFsyXSANCiAg ICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTktc2Vj ZGlzcGF0Y2gtMDEvbWF0ZXJpYWxzL3NsaWRlcy1pbnRlcmltLTIwMTktc2VjZGlzcGF0Y2gtMDEt c2Vzc2EtZWRob2MucGRmDQogICAgPiBbM10gDQogICAgPiBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoLy1HUHFzd25TLURSdnJBS3NQYmRvZXM0WTRsRQ0K ICAgID4gWzRdIA0KICAgID4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9z ZWNkaXNwYXRjaC9ySnF2c3RMSG83YUxmdS1PRHJpbC13SVZuXzANCiAgICA+IFs1XSANCiAgICA+ IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMXdMb0lleE1MRzNVOWlZTzVoekd6 S2prdmktVkRuZFFCYllSTnNNVWxoLWsNCiAgICA+IFs2XSANCiAgICA+IGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY2ZyZy82V04yQzJSWUdUSUFJbkUyaklVY282TDlwTzgN CiAgICA+IFs3XSANCiAgICA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv Y2ZyZy8yT1kyb20xRmpoTk5CbVV6d1lKcm9IdjdlV1ENCiAgICA+IFs4XSBodHRwczovL2FsZXNz YW5kcm9icnVuaS5uYW1lL3BhcGVycy8xOC1lZGhvYy5wZGYNCiAgICA+IFs5XSBodHRwczovL2dp dGh1Yi5jb20vdGhlaXNncm9lbmJlY2gvZWRob2MtcHJvdmVyaWYNCiAgICA+IFsxMF0gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxzLTAxDQogICAgPiBb MTFdIGh0dHBzOi8vZ2l0aHViLmNvbS9iaWZ1cmNhdGlvbi9taW50L2NvbXBhcmUvZnRscw0KICAg ID4gWzEyXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtNnRp c2NoLw0KICAgID4gWzEzXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5Lw0KICAgID4gWzE0XSBodHRwczovL2dpdGh1Yi5jb20v YWxleGtyb250aXJpcy9FREhPQy1DDQogICAgPiBbMTVdIGh0dHBzOi8vZ2l0aHViLmNvbS9qaW1z Y2gvRURIT0MtY3NoYXJwDQogICAgPiBbMTZdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2NoYXJ0ZXItaWV0Zi1scHdhbi8NCiAgICA+IFsxN10gDQogICAgPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1kdHNlY3VyaXR5LXplcm90b3Vj aC1qb2luDQogICAgPiANCiAgICA+ID09WyBFbmQgXT09DQogICAgPiANCiAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBTZWNkaXNwYXRj aCBtYWlsaW5nIGxpc3QNCiAgICA+IFNlY2Rpc3BhdGNoQGlldGYub3JnDQogICAgPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQogICAgPg0KICAgIA0K ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg U2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQogICAgU2VjZGlzcGF0Y2hAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQogICAgDQoN Cg== From nobody Tue Apr 9 08:42:49 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC37120880 for ; Tue, 9 Apr 2019 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8etFBei8xB_f for ; Tue, 9 Apr 2019 08:42:44 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C59A120881 for ; Tue, 9 Apr 2019 08:42:44 -0700 (PDT) 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=IqieYZs48k8/4wb/6793tdqJxhR9kydL8LnrgQkx2qI=; b=GbU3CUJmOZxpGY9fzV7YkZuKtBnt0d442Ajl6idEAUFq8MsSL7R6WajfJ8tUApFyJyDmbbJyoTu+j6TO3wLOEg3u31lYq6If+BmYZ0wd/vnmLhbiri7bTqrsMIH1ZscsehJ7hIvgBe3HBuUBkVfAKPBJzkRDXBUFj+hryUV/hOg= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3466.eurprd07.prod.outlook.com (10.170.247.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Tue, 9 Apr 2019 15:42:42 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888%5]) with mapi id 15.20.1792.007; Tue, 9 Apr 2019 15:42:42 +0000 From: John Mattsson To: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU7urdLGwkiPXZEUCOsU6IRVcrNQ== Date: Tue, 9 Apr 2019 15:42:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fce6644-d07d-461c-995d-08d6bd0200cb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3466; x-ms-traffictypediagnostic: HE1PR07MB3466: x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(366004)(346002)(136003)(199004)(189003)(81156014)(486006)(1730700003)(6916009)(8936002)(25786009)(81166006)(53936002)(2906002)(44832011)(8676002)(33656002)(5660300002)(478600001)(5640700003)(6512007)(229853002)(6486002)(36756003)(316002)(66066001)(14454004)(86362001)(6506007)(102836004)(305945005)(2501003)(186003)(3846002)(4744005)(6116002)(6436002)(83716004)(97736004)(476003)(256004)(6246003)(14444005)(2616005)(105586002)(26005)(2351001)(58126008)(68736007)(82746002)(71190400001)(71200400001)(7736002)(106356001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3466; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 24hi8FL36iLWC2jYsWt6TV34fQ+GVg8AJmRYlR6OxAUeXICSc+10w5bZRSKQkuVAUBx0Zwi8u9Rma1Pnj0cfVa+wuWPzNGYDh2TY8zpagQZh0N3wUP7YQ0r2gdUo9l5JUh2vGaRkX0fqtVnD/slbhwQWNiu8CgDPMbDd4D1izDkIgBbCfL5Ih4ktT5IMh3Pwdciln5ltO2lDPd8QP4qdjzWUeEBiT/Xknc4KgGnZOtfQSSaV4zG7Z0t4TEXB372roGxR2WKwFiQBSa8hVFg0de6+f9F6Hz0lUHYyIjtDvDJZg6kvgSwusJ0fJMLqdpZD+TVntl2XPNTVpM1LhtRWL/97Do+uW/5TBr3fgzFUU+atoPSv2tDsKMet0mbvz2Yirp4rPWQUixJ/OLKdWIRE0yrKBsbD+aSUzJSW0NHAUqw= Content-Type: text/plain; charset="utf-8" Content-ID: <3AAF41C4DFCC0948810043E5EDA4E8AD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fce6644-d07d-461c-995d-08d6bd0200cb X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 15:42:41.8499 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3466 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 15:42:47 -0000 Q29vbCwgSSBvbmNlIHdvcmtlZCBhdCBhIG51Y2xlYXIgcG93ZXIgcGxhbnQgZm9yIGEgc2hvcnQg cGVyaW9kLiBBTEFSQSBpcyBhbiBleGNlbGxlbnQgdGVybSB0aGF0IGRlZmluaXRlbHkgbWFrZXMg c2Vuc2UgaW4gbWFueSBDb25zdHJhaW5lZC1Ob2RlIE5ldHdvcmtzLCBJIHRoaW5rIHlvdSBzaG91 bGQgY29uc2lkZXIgYWRkaW5nIGl0IHRvIFJGQzcyMjhiaXMuDQoNClRoZSB0ZXJtIEFMQVJQIChB cyBMb3cgQXMgUmVhc29uYWJseSBQb3NzaWJsZSkgaXMgYSBzaW1pbGFyIHZlcnkgY29tbW9ubHkg dXNlZCBsYXcgYW5kIGVuZ2luZWVyaW5nIHRlcm0gZm9yIGFsbCB0eXBlIG9mIHJpc2sgbWFuYWdl bWVudCwgbm90IG9ubHkgbnVjbGVhci4NCg0KQnV0IGZvciBMUFdBTiBvdmVyIExvUmFXYW4gYW5k IDZUaVNDSCwgdGhlIGN1cnJlbnQgcmVxdWlyZW1lbnQgcmVnYXJkaW5nIG1lc3NhZ2Ugc2l6ZXMg YXJlIHZlcnkgY29uY3JldGUuDQoNCkpvaG4NCg0KQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5v cmc+IHdyb3RlOg0KDQpPciAxOC41IG1iaXQvcyAoeWVzLCBtaWxsaWJpdHMpLg0KDQpNaWxsaWJp dCBuZXR3b3JrcyBpcyBvbmUgb2YgdGhlIHNjZW5hcmlvcyB3aGVyZSBBTEFSQSgqKSBhcyBhIGRl c2lnbiBvYmplY3RpdmUgZG9lcyBtYWtlIHNlbnNlIOKAlCB0aGVyZSBpcyBubyBoYXJkIGRlc2ln biBsaW1pdCwgYnV0IGFjdHVhbCBzZWN1cml0eSB3aWxsIG5lZWQgdG8gY29tcGV0ZSB3aXRoIGxl c3Mgc2VjdXJpdHksIGFuZCBBTEFSQSBoZWxwcyBhY3R1YWwgc2VjdXJpdHkgc3RheSBjb21wZXRp dGl2ZS4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQooKikgQUxBUkE6IOKAnEFzIGxvdyBhcyByZWFz b25hYmx5IGFjaGlldmFibGUiLCBhIHRlcm0gc3RvbGVuIGZyb20gbnVjbGVhciBlbmdpbmVlcmlu Zy4NCg0K From nobody Tue Apr 9 18:51:38 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9BB12013F for ; Tue, 9 Apr 2019 18:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_FROM_FMBLA_NEWDOM14=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=ZTOj1z4Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Sv6579bc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axjS2qGtcABm for ; Tue, 9 Apr 2019 18:51:36 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8AB12015D for ; Tue, 9 Apr 2019 18:51:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 90D1314636 for ; Tue, 9 Apr 2019 21:51:35 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 09 Apr 2019 21:51:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=dhz/A YxPECraHgjZyWg1NugLN0pZ7TG7F7XyCawZYqc=; b=ZTOj1z4Y9s64mOIRKv3Lu DNxQpLmJo3zzngvSAT41CRQKX9cm3Ch2rizF69FNl/3Ql2B9zXK+jrT/J2VmM1TQ ZsH26TsRhmN4vvfoPtbdxaDsewypuEySDYo1Vmp/bCRyY280S++3RnzD429bCWGg 5eMfjFBJF51gV2pETfnp6PYXMpfEK7Ts+7xYrXpCqDxKNToMjdwC8rl9hg4Eu8Jm z6A/TMpBbVYIUBNiXUB0ZkD7L0lSYt5W8WTkXLGKHEFcs4JEvBlRN9TnWywzloOx Hhk9sYOkJ4w2P8lPdfShcGYOvO55uc07vKNwwi/EzX6qcH9V7xnNU6OcdRRNqNJR A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=dhz/AYxPECraHgjZyWg1NugLN0pZ7TG7F7XyCawZY qc=; b=Sv6579bcbi7GRMez6gAEOzCl/MLiorsgpwYKT1rLh0aYfoDlFBFpWMl0z vJGnl3LIVlCPrjzS8o7cuAh+8R1sndrAW7+EvqAFy4blLQ9D8JdgqfycM8CT7UAd +XLfmPhhu4k3SfkD6L82E7Dgq0tK6DOElBY+Ai8verUrZdzIJhrWo8oPkDMoNsvQ P7ytULIAqL9WuIS24flvDKy+fpIYgCoOqYPr5O1ItvBXwE4+X3X4qCHTyEQts+yh givAx+t0Zpmb0rDcYIX4s0bAdd4jSxLhNGDv5x9y50Pfx0dXpAs8FEfqlevKqCBW mD722o7jukfe+v6yDEfZyHUKvjo3g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeigdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A0892602F; Tue, 9 Apr 2019 21:51:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 94902928 Message-Id: <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> In-Reply-To: <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> Date: Tue, 09 Apr 2019 21:51:34 -0400 From: "Christopher Wood" To: secdispatch@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 01:51:38 -0000 Hi G=C3=B6ran, Please see inline below. On Tue, Apr 9, 2019, at 4:58 AM, G=C3=B6ran Selander wrote: > Hi Martin, >=20 > Some comments inline. >=20 > =EF=BB=BFOn 2019-04-09, 01:18, "Secdispatch on behalf of Martin Thomso= n"=20 > wrote: >=20 > Hi Roman, Ben, > =20 > I=E2=80=99m a little surprised to see that your conclusion from th= e meeting=20 > we had was so clear. The summary shared at the end of the meeting=20 > highlighted the need to clarify the scope and nature of the=20 > requirements. There has been some discussion on the list on this=20 > subject, but I haven=E2=80=99t seen anything that indicates consensus = around=20 > the problem statement. >=20 > [GS] There seems to be consensus on the summary provided by the=20 > Security ADs, which includes the problem statement. >=20 > The framing of this summary seems to imply that the goal is to wor= k=20 > on EDHOC. That seems premature. There seems to be agreement that the= =20 > authenticated key exchange (AKE) protocols we have are inefficient in=20= > ways that affect these deployments. That doesn=E2=80=99t naturally imp= ly that=20 > EDHOC is a solution, only that there is a need to have an efficient AK= E=20 > protocol. >=20 > [GS] There is no competing solution to the problem statement. As been=20= > witnessed, people have waited for years for this to progress. Therefor= e=20 > I don't see anything premature with assuming EDHOC to be a starting=20= > point for the WG.=20 >=20 > =E2=80=9CAs cheap as possible=E2=80=9D is not a problem statement = that is=20 > sufficiently precise to be acted upon. For example, the analysis for=20= > LoRaWAN seemed to support the conclusion that ANY key exchange protoco= l=20 > would fail badly, no matter how small, fast, or efficient. For=20 > deployments with capabilities that might support an AKE, we have no=20= > grounds for determining whether 5nJ or 1 octet difference is acceptabl= e=20 > or not. Concrete objectives - ideally targets with numbers - are neede= d=20 > if we=E2=80=99re to assess solutions. > =20 > [GS] Concrete targets with numbers have been presented, for example he= re: > https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjO= pLjZGCU >=20 > Even assuming that requirements are settled, I believe that there=20= > are considerations that go beyond the narrow definition of the problem= =20 > statement. In the recent review of the T2TRG, I was reminded of their=20= > goal: > =20 > > The Thing-to-Thing Research Group (T2TRG) will investigate open=20= > research issues in turning a true "Internet of Things" into reality, a= n=20 > Internet where low-resource nodes ("things", "constrained nodes") can=20= > communicate among themselves and with the wider Internet, in order to=20= > partake in permissionless innovation. > =20 > Though a little wordy, I think that this is a fine goal to keep in= =20 > mind. Deciding to create a working group specifically for EDHOC makes= =20 > a determination directly in opposition to this goal. We=E2=80=99ve ma= de=20 > similar choices for application protocols like CoAP. For CoAP, the=20= > agreed fix was gateways and proxies. For a security protocol, that is= =20 > not an option if you value end-to-end security. > =20 > [GS] A lightweight AKE on application layer, which this specific WG is= =20 > proposed to work on, is actually a missing enabler for constrained=20 > nodes to "communicate among themselves and with the wider Internet".=20= > Indeed, if the security protocol is too heavy or needs to terminate in= =20 > a gateway due to change of transport etc., then end-to-end secure=20 > communication between the endpoints will not take place, thus=20 > preventing "to partake in permissionless innovation". =20 >=20 If what=E2=80=99s missing is a lightweight AKE protocol, then shouldn=E2= =80=99t the purpose of this WG be to first identify what lightweight mea= ns? To reiterate (my understanding of) Martin=E2=80=99s point, it seems = the requirements do not have consensus, and therefore choosing a specifi= c AKE is a bit premature. It seems prudent to first get a shared underst= anding of the problem space and requirements before we trim the solution= space. Best, Chris From nobody Tue Apr 9 19:57:26 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90512120143 for ; Tue, 9 Apr 2019 19:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=i30xwR+d; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CIoCrU/N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd_pOOqavcqA for ; Tue, 9 Apr 2019 19:57:22 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456FA12009C for ; Tue, 9 Apr 2019 19:57:22 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5318E264E0; Tue, 9 Apr 2019 22:57:21 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 09 Apr 2019 22:57:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=yolbJ jG0KtY+DPL6VX/WKJajt3SmHnH5HPwk2d4SX5o=; b=i30xwR+dTHv3D/+2jHbCt S+Y6w1ynsowwBFbfEbi2M3fyCbg+YvzXg4BnqLhEnrKWili9J2vEBiozTn2G7ie3 6JIWfw88ezHIRKSC+MvIv2sg5GVfs7ZguMj5pn987yNS1VQwXJ5dWgC0jQEHHCDD tuf/ySrprDE/ZFH0rb1wPBZcidHSjmm4VJvze/3h4GGKIWZYh107DE1t+kAjeJeV KyP9XftXoXsHKkKva7e9MRRdWz7uaWCz/9zXiTEHoRAn5fNaNg/rO+c3bewQocd1 lZscXXceDD7l6PtmGszK7i1S3zd1uf37Ff60K1WbxVnPnMR99EvPOx+2+M4ShIow w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=yolbJjG0KtY+DPL6VX/WKJajt3SmHnH5HPwk2d4SX 5o=; b=CIoCrU/NruanTpiPbmg7fjiEe1znNJtZeYoo4aVN4tW3grSdVyjr6Yvdt B8lbZR2zLcIYNTwU9C0WRKLyhUVF+33CMsbXSZUC9513Z2+4W9l6p/qLNaphuu1m nDKN2FK2bkV7SAXXSmA0a0EzotdlfcskivaKCSTgfafvnOdBwDswt1ZPC86TtAJ3 BblBZWXkjdGCV2DE7fVicezqqGomyAQyGz07eemUl2k9/XdYaeZtMBDF95FIN5NV WuqCrZCD2W56Mkd+XOUOJrxRGMmV6j0gqr7UOO885VeZgyQHndHCo7Bhjbbr6PdA wvW2kYDmSFBhoa2uQLGQT5SCB/CqQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeigdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehl ohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C2C0F7C1B9; Tue, 9 Apr 2019 22:57:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> In-Reply-To: <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> Date: Tue, 09 Apr 2019 22:57:22 -0400 From: "Martin Thomson" To: =?UTF-8?Q?G=C3=B6ran_Selander?= , "secdispatch@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 02:57:25 -0000 On Tue, Apr 9, 2019, at 21:57, G=C3=B6ran Selander wrote: > [GS] There seems to be consensus on the summary provided by the=20 > Security ADs, which includes the problem statement. The entire point of my mail was to contest that point. =20 > [GS] There is no competing solution to the problem statement. As been=20= > witnessed, people have waited for years for this to progress. Therefor= e=20 > I don't see anything premature with assuming EDHOC to be a starting=20= > point for the WG.=20 So you would prefer to disregard the work done by Eric and Jim completel= y? =20 > [GS] Concrete targets with numbers have been presented, for example he= re: > https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjO= pLjZGCU Presented, yes. Agreed, no. > [GS] A lightweight AKE on application layer, which this specific WG is= =20 > proposed to work on, is actually a missing enabler for constrained=20 > nodes to "communicate among themselves and with the wider Internet".=20= > Indeed, if the security protocol is too heavy or needs to terminate in= =20 > a gateway due to change of transport etc., then end-to-end secure=20 > communication between the endpoints will not take place, thus=20 > preventing "to partake in permissionless innovation". =20 I think that you missed my point. If the goal is to provide an AKE, the= n any AKE will do. If the goal is to communicate with other Internet no= des, then you might argue that any AKE will do, but you at least have to= consider what existing Internet nodes do in making that call. From nobody Tue Apr 9 23:59:15 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006FC1202B2 for ; Tue, 9 Apr 2019 23:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4zl7HoFcsgpn for ; Tue, 9 Apr 2019 23:59:11 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70058.outbound.protection.outlook.com [40.107.7.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1AE12001E for ; Tue, 9 Apr 2019 23:59:11 -0700 (PDT) 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=VaWDzIIfj5m5uGIOcOpjVRi0cidX8awBi5FM/48tJ2g=; b=B3easN+2ZiGhFj4E3VhQ9BRTckK35cWcJYzE8bFLYxpqTromesav0aMMbVrqoN/+hrMUZjazjS3w1vKg5o3sThdZ0fyUqC6gDTiw52A4u8Ezu220CGNEkbIMY5takg6aRwPFxArElk6tlmz+2hqiX5J0pl2oousY2Xu8TXcQ4sk= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3513.eurprd07.prod.outlook.com (10.170.247.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Wed, 10 Apr 2019 06:59:08 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::d49e:f22a:1e0b:f888%5]) with mapi id 15.20.1792.007; Wed, 10 Apr 2019 06:59:08 +0000 From: John Mattsson To: Christopher Wood , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU70ABBpJ7sDqWOEq8H6QVKHzF1qY1GM6A Date: Wed, 10 Apr 2019 06:59:08 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> In-Reply-To: <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bed2a8c3-b1dd-4def-379d-08d6bd820764 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3513; x-ms-traffictypediagnostic: HE1PR07MB3513: x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(366004)(39860400002)(136003)(199004)(189003)(33656002)(7736002)(106356001)(99286004)(2906002)(93886005)(305945005)(105586002)(97736004)(44832011)(6506007)(6116002)(66066001)(102836004)(53936002)(76176011)(6512007)(26005)(5660300002)(36756003)(229853002)(6246003)(58126008)(186003)(6436002)(486006)(8936002)(6486002)(2501003)(476003)(478600001)(110136005)(71200400001)(14454004)(3846002)(68736007)(14444005)(81156014)(81166006)(82746002)(256004)(316002)(86362001)(11346002)(25786009)(446003)(8676002)(83716004)(2616005)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3513; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sozElDCJLqMdnLT4z4zHNnsO611l30Pwx3XvbPXP7Yrc4nCfiL3Q3I11PK71BDp5z9WUuWBcsIPg0mL6fZJVx1uDv75RJZQF+17C7PiArXjUYBD1nrBeTQyHe5iUkk66NjRiv/szIVC0m/n1pwhfV5w3ShU5Jd1fAyNhKABDGQUNQuEoNf9wgNh8AfJRPfGsTWmFRczfCRGoYGVa2lo/WYsqPILazr8Nn+88VgQ9594mRMeZEQsMv9zL09m2RxBz57x8h4dZj3X1voYvI5kQ27K2E4MLlMBRPpbP2fAkJPr+X1aybMO8dyqOJZSXALuntN87ejn4Z2k7H21MbjwJMFB5N619E1W73RIa/hMAlWu+YHTyJmyWaGEQlYTPgftLhI02/JTTwWY3BQY4navQaCBNfjXe/gwkdNhFs3zZOOQ= Content-Type: text/plain; charset="utf-8" Content-ID: <9F669D7D7A3EFE42AC7A4F7A79D6FFC4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bed2a8c3-b1dd-4def-379d-08d6bd820764 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 06:59:08.4828 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3513 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 06:59:14 -0000 SGkgQ2hyaXMsDQoNCkNocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+IHdyb3Rl Og0KDQo+SWYgd2hhdOKAmXMgbWlzc2luZyBpcyBhIGxpZ2h0d2VpZ2h0IEFLRSBwcm90b2NvbCwg dGhlbiBzaG91bGRu4oCZdCB0aGUgcHVycG9zZSBvZiB0aGlzIFdHIGJlIHRvIGZpcnN0IGlkZW50 aWZ5IHdoYXQgPmxpZ2h0d2VpZ2h0IG1lYW5zPyBUbyByZWl0ZXJhdGUgKG15IHVuZGVyc3RhbmRp bmcgb2YpIE1hcnRpbuKAmXMgcG9pbnQsIGl0IHNlZW1zIHRoZSByZXF1aXJlbWVudHMgZG8gbm90 IGhhdmUgPmNvbnNlbnN1cywgYW5kIHRoZXJlZm9yZSBjaG9vc2luZyBhIHNwZWNpZmljIEFLRSBp cyBhIGJpdCBwcmVtYXR1cmUuIEl0IHNlZW1zIHBydWRlbnQgdG8gZmlyc3QgZ2V0IGEgc2hhcmVk ID51bmRlcnN0YW5kaW5nIG9mIHRoZSBwcm9ibGVtIHNwYWNlIGFuZCByZXF1aXJlbWVudHMgYmVm b3JlIHdlIHRyaW0gdGhlIHNvbHV0aW9uIHNwYWNlLg0KIA0KVGhlIHVzZSBjYXNlcyBhbmQgcmVx dWlyZW1lbnRzIGZvciBsaWdodHdlaWdodCBwcm90b2NvbHMgaW5jbHVkaW5nIGxpZ2h0d2VpZ2h0 IHNlY3VyaXR5IHByb3RvY29scyBmb3IgY29uc3RyYWluZWQgSW9UIGhhdmUgYmVlbiBkaXNjdXNz ZWQgZm9yIHllYXJzIGluIHRoZSBJRVRGIElvVCB3b3JraW5nIGdyb3VwcyAoQ09SRSwgQUNFLCBU MlRSRywgNlRpU0NILCBMV0lHLCBMUFdBTiwgNmxvLCBldGMuKS4gSUVTRyB0b29rIHRoZSBkZWNp c2lvbiBhIGZldyB5ZWFyIGFnbyB0aGF0IElFVEYgV0dzIHNob3VsZCBpbiBnZW5lcmFsIG5vdCBk byByZXF1aXJlbWVudCBhbmQgdXNlIGNhc2UgUkZDcy4gUkZDNzIyOCAoYW5kIFJGQzcyMjhiaXMp IGdpdmVzIGFuIGV4Y2VsbGVudCBvdmVydmlldyBvZiB0aGUgd2lkZSBzcGFuIG9mIElvVCBkZXZp Y2VzIGFuZCBuZXR3b3JrcyBhbmQgaG93IHV0dGVybHkgY29uc3RyYWluZWQgc29tZSBvZiB0aGVt IGFyZS4gRm9yIHRoZSB0YXJnZXQgbmV0d29yayB0ZWNobm9sb2dpZXMgTFBXQU4gb3ZlciBMb1Jh V0FOIGFuZCA2VGlTQ0ggb3ZlciBJRUVFIDgwMi4xNS40LCB0aGUgcmVxdWlyZW1lbnRzIGZvciBt ZXNzYWdlIHNpemUgYXJlIGNsZWFyICh1bmRlciA1MCBieXRlcykuDQoNCkNoZWVycywNCkpvaG4N Cg0K From nobody Wed Apr 10 00:26:22 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168971202B5 for ; Wed, 10 Apr 2019 00:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmD55vYmS2Oo for ; Wed, 10 Apr 2019 00:26:18 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331C71200F8 for ; Wed, 10 Apr 2019 00:26:18 -0700 (PDT) Received: from [192.168.217.106] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44fG142FTmzyYt; Wed, 10 Apr 2019 09:26:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> Date: Wed, 10 Apr 2019 09:26:15 +0200 Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , "secdispatch@ietf.org" X-Mao-Original-Outgoing-Id: 576573973.791877-6b58e3d28386f23e907fbc305eb41808 Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 07:26:21 -0000 On Apr 10, 2019, at 04:57, Martin Thomson wrote: >=20 >> [GS] There is no competing solution to the problem statement. As been=20= >> witnessed, people have waited for years for this to progress. = Therefore=20 >> I don't see anything premature with assuming EDHOC to be a starting=20= >> point for the WG.=20 >=20 > So you would prefer to disregard the work done by Eric and Jim = completely? I can=E2=80=99t answer that question for G=C3=B6ran, but personally I = really like that there are now fresh proposals for addressing TLS = handshake size. Those proposals already do have a natural WG to do the = work on them, the TLS WG, so no new WG is needed for those; if some = rechartering of the TLS WG is required for that, I=E2=80=99m all for = picking up that work there. We also need a low-resource authenticated key agreement protocol that we = can use now, and EDHOC is the only one I=E2=80=99m aware of that is in a = stage of development where it can meet the timelines of the protocols = depending on it. The main problem that we have had in completing the = work was that there was no WG to assign this work to, and we need to fix = this now. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 10 01:10:17 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A354512012A for ; Wed, 10 Apr 2019 01:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 aePozvVWW-kw for ; Wed, 10 Apr 2019 01:10:13 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70079.outbound.protection.outlook.com [40.107.7.79]) (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 EAE551200FE for ; Wed, 10 Apr 2019 01:10:12 -0700 (PDT) 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=l//YFoADrs6E5rQ30/POJ6KyU5cL5jj1Yp+toyCJ2hs=; b=R8JvIF3QVS9ZCDQHFF4Fcq5auhDbLqAZ13K9yJBIwd9YR5R0MPaHGbCAIJRPQUhVWvmB/Da04YfGEgVlZ4K5LX2f5iInxz6jMzmFgWqVxoONOLua1apa7tHvZZvPJ3HkaDcKSoCaCQC7kI1xK/M2R/miGLzuz37ARvm/aaJzGFE= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3307.eurprd07.prod.outlook.com (10.170.246.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Wed, 10 Apr 2019 08:10:09 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Wed, 10 Apr 2019 08:10:09 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Christopher Wood , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAJEpqUAAB7BU4AAGO0gAAARaYkA Date: Wed, 10 Apr 2019 08:10:09 +0000 Message-ID: <9B8B8EDC-354B-44FF-A502-1F40E7FF6946@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> In-Reply-To: <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa727282-675f-4187-1f06-08d6bd8bf324 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3307; x-ms-traffictypediagnostic: HE1PR07MB3307: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(366004)(396003)(199004)(189003)(102836004)(53936002)(8676002)(33656002)(81156014)(8936002)(186003)(105586002)(6246003)(81166006)(7736002)(68736007)(6506007)(6436002)(26005)(6486002)(85202003)(93886005)(229853002)(58126008)(110136005)(106356001)(6512007)(6306002)(66066001)(2906002)(305945005)(316002)(99286004)(36756003)(76176011)(561944003)(85182001)(97736004)(71200400001)(83716004)(71190400001)(25786009)(6116002)(446003)(82746002)(86362001)(14454004)(14444005)(11346002)(966005)(2501003)(5660300002)(256004)(66574012)(2616005)(478600001)(486006)(476003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3307; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 75GQnemeAoqOMhRrcfvNR2GRMN5tcSKVF3nHlpwfZtUW+RwsI8iMmJvQVQwcYpbDLzqdG1cZghmcb2c+n6HVmNeAVFNfPjQhehAvRCkPdQSuS0uZ3TKVcZIoSPMqhEyVGlLwrokqYktKhZUF5Fi+B/Bo2f/mCzWmYoRpOnASS8HP3GN6Llrk5mDzz8sejaSnsXDmAJ+YicFDJiTKUuVY147uE7ulQ2kKjh7cppOzXhWsHdPiNYwc6zj3YsWSBFnKD0TDVEipp4MAFdSWuHeWZr1cFAKm+aDDJJmS3KMxhCpBS/bYAohFYNRZjosnvbLWCegaCqqHkQ9CvFL4mkt2J6aBZHNic9stXaZUhPfldoQEbPelCDKWYCfhvIILsUPxeWfLr0JdUpUH8twxe4cBO5SWs9PRVjZdSOX13J9S6kY= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa727282-675f-4187-1f06-08d6bd8bf324 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 08:10:09.5697 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3307 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 08:10:16 -0000 SGkgQ2hyaXMsDQoNCu+7v09uIDIwMTktMDQtMTAsIDAzOjUyLCAiU2VjZGlzcGF0Y2ggb24gYmVo YWxmIG9mIENocmlzdG9waGVyIFdvb2QiIDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBjYXdAaGVhcGluZ2JpdHMubmV0PiB3cm90ZToNCg0KICAgIEhpIEfDtnJhbiwN CiAgICANClstIC0gLV0NCg0KICAgIElmIHdoYXTigJlzIG1pc3NpbmcgaXMgYSBsaWdodHdlaWdo dCBBS0UgcHJvdG9jb2wsIHRoZW4gc2hvdWxkbuKAmXQgdGhlIHB1cnBvc2Ugb2YgdGhpcyBXRyBi ZSB0byBmaXJzdCBpZGVudGlmeSB3aGF0IGxpZ2h0d2VpZ2h0IG1lYW5zPyBUbyByZWl0ZXJhdGUg KG15IHVuZGVyc3RhbmRpbmcgb2YpIE1hcnRpbuKAmXMgcG9pbnQsIGl0IHNlZW1zIHRoZSByZXF1 aXJlbWVudHMgZG8gbm90IGhhdmUgY29uc2Vuc3VzLCBhbmQgdGhlcmVmb3JlIGNob29zaW5nIGEg c3BlY2lmaWMgQUtFIGlzIGEgYml0IHByZW1hdHVyZS4gSXQgc2VlbXMgcHJ1ZGVudCB0byBmaXJz dCBnZXQgYSBzaGFyZWQgdW5kZXJzdGFuZGluZyBvZiB0aGUgcHJvYmxlbSBzcGFjZSBhbmQgcmVx dWlyZW1lbnRzIGJlZm9yZSB3ZSB0cmltIHRoZSBzb2x1dGlvbiBzcGFjZS4NCg0KW0dTOl0NCg0K VGhlIHB1cnBvc2Ugb2YgdGhlIFNlY2Rpc3BhdGNoIGludGVyaW0gbWVldGluZyBvbiBNYXJjaCAw NSwgdGhlIHByZWNlZGluZyBhbmQgZm9sbG93aW5nIGRpc2N1c3Npb24gd2FzIHRvIGRldGFpbCB0 aGUgcmVxdWlyZW1lbnRzIChhbmQgcHJlc2VudCB0aGUgcmVzdWx0cyBvZiB0aGUgc2VjdXJpdHkg YW5hbHlzaXMpLiBPdXIgcG9zdC1pbnRlcmltIGNvbXBpbGF0aW9uIG9mIHRoZSB1c3VhbCBCb0Yg cXVlc3Rpb25zIGluY2x1ZGluZyByZXF1aXJlbWVudHMgKGFuZCBzcGVjaWZpY2F0aW9uIG9mICds aWdodHdlaWdodCcpIGlzIGhlcmU6DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL3NlY2Rpc3BhdGNoL3ZOUjduVDIwZnN2WWpZWGhBUGpPcExqWkdDVQ0KDQpUaGUgc2VjdXJp dHkgQURzJyBjb25jbHVzaW9uIG9mIHRoZSB3aG9sZSBkaXNjdXNzaW9uIGFuZCBwcm9wb3NhbCBm b3IgbmV4dCBzdGVwcywgaW5jbHVkaW5nIGEgcmVxdWVzdCBmb3IgY29tbXVuaXR5IGZlZWRiYWNr ICh3aGljaCBlbmRlZCBvbiBNb25kYXkpIGlzIGhlcmU6IA0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC9Lel82eTZKcTRIc1d4Z2xzVUhhZldqWEltMGMN Cg0KSSBvbmx5IHNlZSBhIGxhcmdlIG51bWJlciBvZiBwZW9wbGUgYWdyZWVpbmcgYW5kIG5vIHRl Y2huaWNhbCBhcmd1bWVudCBhZ2FpbnN0Lg0KDQpBcG9sb2dpZXMgZm9yIG15IGltcGF0aWVuY2Us IGJ1dCB0aGUgZGlzY3Vzc2lvbiBpcyBvdmVyIDIgeWVhcnMgb2xkLiBUaGUgcGVvcGxlIGNvbnRl c3RpbmcgdGhpcyB3b3JrIGhhcyBiZWVuIGFnYWluc3QgaXQgZm9yIGEgbG9uZyB0aW1lIGFuZCB0 aGUgYXJndW1lbnQgaGFzIHNoaWZ0ZWQgZnJvbSAidGhlIFRMUyBoYW5kc2hha2UgaXMgbGlnaHR3 ZWlnaHQiIHRvICJ0aGVyZSBpcyBubyBuZWVkIGZvciBhIGxpZ2h0d2VpZ2h0IGhhbmRzaGFrZSIg dG8gIk9LLCB3ZSBuZWVkIGEgbGlnaHR3ZWlnaHQgaGFuZHNoYWtlLCBidXQgbm90IGFzIGxpZ2h0 d2VpZ2h0IGFzIEVESE9DIi4gKFRoZSBsYXN0IHN0YXRlbWVudCBpcyBzbGlnaHRseSBkaXN0b3J0 aW5nIHRoZSBhcmd1bWVudCwgYnV0IGp1c3QgdG8gZ2l2ZSB0aGUgaWRlYS4pDQoNCkfDtnJhbg0K DQoNCiAgICBCZXN0LA0KICAgIENocmlzDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBTZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QN CiAgICBTZWNkaXNwYXRjaEBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2VjZGlzcGF0Y2gNCiAgICANCg0K From nobody Wed Apr 10 01:24:07 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA71202D0 for ; Wed, 10 Apr 2019 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 aDlisa3WkIST for ; Wed, 10 Apr 2019 01:24:02 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30082.outbound.protection.outlook.com [40.107.3.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB941202CF for ; Wed, 10 Apr 2019 01:24:02 -0700 (PDT) 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=cxDdZ9XoDBXLpRgZm29TR2UKpSVDfZXbRuRfIzxJnZA=; b=XPydfc/1xj9kx8ucE8inP2A2DGMsqjqxgG60uE/v+UVXs7RI5lu6kpufGQxHmSo/AwLilqWDC4uI9yD+kzYYo8tIujQS5ZOUsB73yb/jRGC5ED/xypTk6vNjwH4rsrb56tCbSJfVaq+TH4e9FUpYYvMTyheUDKalDzqp+AzmayY= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3420.eurprd07.prod.outlook.com (10.170.247.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Wed, 10 Apr 2019 08:23:59 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Wed, 10 Apr 2019 08:23:59 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Martin Thomson , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAJEpqUAAB7BU4AAGzlsAAAPmRGA Date: Wed, 10 Apr 2019 08:23:59 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> In-Reply-To: <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d427bda-7439-4172-ac89-08d6bd8de204 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3420; x-ms-traffictypediagnostic: HE1PR07MB3420: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(136003)(366004)(346002)(396003)(189003)(199004)(51444003)(6486002)(106356001)(85202003)(25786009)(53936002)(6512007)(2906002)(6116002)(6436002)(14444005)(186003)(105586002)(256004)(6246003)(6306002)(3846002)(81166006)(66066001)(71190400001)(85182001)(71200400001)(83716004)(8936002)(8676002)(81156014)(229853002)(66574012)(82746002)(93886005)(5660300002)(476003)(36756003)(7736002)(486006)(305945005)(99286004)(58126008)(97736004)(2616005)(446003)(11346002)(14454004)(966005)(86362001)(33656002)(68736007)(316002)(26005)(6506007)(102836004)(2501003)(478600001)(76176011)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3420; H:HE1PR07MB4172.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-message-info: yKEkByvjSU6G0702Yv4P589XH4lcCYJYoqSl1DTE1E/SAcLjdzu6SCTyDqlFzFA8FNEvo2+vdsmhEd76l1t6kr6ZLhHMVKq2zQaRluik3K1QhHrCChQglMfoIHmHEwc9tVfoQTXTS0DHbtgeADj7Xy9P+ZEUnJ2W6fHYosFTyko0UmbGaCy+aUsFrFdou7NYQuF/7o3qD6BviC/F5sxSwDimko2riZULTldHhwv7dvgsww47+s1AZe9yU+q+BIrr8oMeaQZbjnqLc2Bl5jZAdNdAXRC5G/vHJpuhKPOhyU60zk0h+3MRDnISZ4D4bKxxErvGhrQYCJwP4r0gMvQR7P6lkHqS6kbi/pzsEPrC/msHBd75P6eysrHQF8hVQ+TvngHrivpQ4hg4VUuJr+gYcfd2xwAmeK0uoknn+kJPYCM= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d427bda-7439-4172-ac89-08d6bd8de204 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 08:23:59.7498 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3420 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 08:24:05 -0000 SGkgTWFydGluLA0KDQpDb21tZW50cyBpbmxpbmUsIHNsaWdodGx5IG92ZXJsYXBwaW5nIHdpdGgg Q2Fyc3RlbidzIHJlc3BvbnNlLg0KDQrvu79PbiAyMDE5LTA0LTEwLCAwNDo1NywgIk1hcnRpbiBU aG9tc29uIiA8bXRAbG93ZW50cm9weS5uZXQ+IHdyb3RlOg0KDQogICAgT24gVHVlLCBBcHIgOSwg MjAxOSwgYXQgMjE6NTcsIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCiAgICA+IFtHU10gVGhlcmUg c2VlbXMgdG8gYmUgY29uc2Vuc3VzIG9uIHRoZSBzdW1tYXJ5IHByb3ZpZGVkIGJ5IHRoZSANCiAg ICA+IFNlY3VyaXR5IEFEcywgd2hpY2ggaW5jbHVkZXMgdGhlIHByb2JsZW0gc3RhdGVtZW50Lg0K ICAgIA0KICAgIFRoZSBlbnRpcmUgcG9pbnQgb2YgbXkgbWFpbCB3YXMgdG8gY29udGVzdCB0aGF0 IHBvaW50Lg0KDQpbR1NdIEkgdW5kZXJzdGFuZCB0aGF0IHlvdSBkbywgYnV0IG5vdCBvbiB3aGF0 IGdyb3VuZHMuIEEgZGV0YWlsZWQgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgcHJlc2VudGVkLCBzdW1t YXJpemVkIGFuZCBhbiBvdmVyd2hlbG1pbmcgY3Jvd2QgYWdyZWUuDQogICAgIA0KICAgID4gW0dT XSBUaGVyZSBpcyBubyBjb21wZXRpbmcgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gc3RhdGVtZW50 LiBBcyBiZWVuIA0KICAgID4gd2l0bmVzc2VkLCBwZW9wbGUgaGF2ZSB3YWl0ZWQgZm9yIHllYXJz IGZvciB0aGlzIHRvIHByb2dyZXNzLiBUaGVyZWZvcmUgDQogICAgPiBJIGRvbid0IHNlZSBhbnl0 aGluZyBwcmVtYXR1cmUgd2l0aCBhc3N1bWluZyBFREhPQyB0byBiZSBhIHN0YXJ0aW5nIA0KICAg ID4gcG9pbnQgZm9yIHRoZSBXRy4gDQogICAgDQogICAgU28geW91IHdvdWxkIHByZWZlciB0byBk aXNyZWdhcmQgdGhlIHdvcmsgZG9uZSBieSBFcmljIGFuZCBKaW0gY29tcGxldGVseT8NCg0KW0dT XSBBcyBoYXMgYmVlbiByZXBlYXRlZCBtYW55IHRpbWVzIG5vdywgd2Ugd291bGQgaW5kZWVkIGxp a2UgdG8gc2VlIHdvcmsgb24gYW4gb3B0aW1pemVkIHZlcnNpb24gb2YgdGhlIFRMUyBoYW5kc2hh a2UgaW4gdGhlIFRMUyBXRy4gQnV0IGFzIHRoYXQgZG9lcyBub3QgY29tcGx5IHdpdGggdGhlIHJl cXVpcmVtZW50cyBoZXJlIHNvbWV0aGluZyBlbHNlIGlzIG5lZWRlZCBpbiB0aGlzIGNhc2UuDQog ICAgIA0KICAgID4gW0dTXSBDb25jcmV0ZSB0YXJnZXRzIHdpdGggbnVtYmVycyBoYXZlIGJlZW4g cHJlc2VudGVkLCBmb3IgZXhhbXBsZSBoZXJlOg0KICAgID4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC92TlI3blQyMGZzdllqWVhoQVBqT3BMalpHQ1UN CiAgICANCiAgICBQcmVzZW50ZWQsIHllcy4gIEFncmVlZCwgbm8uDQoNCltHU10gVGhlIHB1cnBv c2Ugb2YgdGhlIGRpc2N1c3Npb24gb24gdGhpcyBtYWlsaW5nIGxpc3QgYW5kIHRoZSBwcm9jZXNz IGFzIHByZXNlbnRlZCBieSB0aGUgc2VjdXJpdHkgQURzIHdhcyB0byBlbmFibGUgYSB0ZWNobmlj YWwgZGlzY3Vzc2lvbiB0byByZWFjaCBhbiBhZ3JlZW1lbnQgb24gaG93IHRvIGRpc3BhdGNoLiBU aGUgdGVjaG5pY2FsIGRpc2N1c3Npb24gaGFzIGJlZW4gZ29pbmcgb24gdGhpcyBsaXN0IGZvciBt b250aHMsIGEgc3VtbWFyeSB3YXMgcHJlc2VudGVkIGJ5IHRoZSBBRHMNCihodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoL0t6XzZ5NkpxNEhzV3hnbHNVSGFm V2pYSW0wYykNCiBhbmQgbm8gdGVjaG5pY2FsIGFyZ3VtZW50IGFnYWluc3QgaGFzIGJlZW4gZ2l2 ZW4gd2l0aGluIHRoZSBzdGlwdWxhdGVkIHRpbWUuIElmIHRoYXQgaXMgbm90IGFncmVlbWVudCwg d2hhdCBpcz8NCiAgICANCiAgICA+IFtHU10gQSBsaWdodHdlaWdodCBBS0Ugb24gYXBwbGljYXRp b24gbGF5ZXIsIHdoaWNoIHRoaXMgc3BlY2lmaWMgV0cgaXMgDQogICAgPiBwcm9wb3NlZCB0byB3 b3JrIG9uLCBpcyBhY3R1YWxseSBhIG1pc3NpbmcgZW5hYmxlciBmb3IgY29uc3RyYWluZWQgDQog ICAgPiBub2RlcyB0byAgImNvbW11bmljYXRlIGFtb25nIHRoZW1zZWx2ZXMgYW5kIHdpdGggdGhl IHdpZGVyIEludGVybmV0Ii4gDQogICAgPiBJbmRlZWQsIGlmIHRoZSBzZWN1cml0eSBwcm90b2Nv bCBpcyB0b28gaGVhdnkgb3IgbmVlZHMgdG8gdGVybWluYXRlIGluIA0KICAgID4gYSBnYXRld2F5 IGR1ZSB0byBjaGFuZ2Ugb2YgdHJhbnNwb3J0IGV0Yy4sIHRoZW4gZW5kLXRvLWVuZCBzZWN1cmUg DQogICAgPiBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGVuZHBvaW50cyB3aWxsIG5vdCB0YWtl IHBsYWNlLCB0aHVzIA0KICAgID4gcHJldmVudGluZyAidG8gcGFydGFrZSBpbiBwZXJtaXNzaW9u bGVzcyBpbm5vdmF0aW9uIi4gIA0KICAgIA0KICAgIEkgdGhpbmsgdGhhdCB5b3UgbWlzc2VkIG15 IHBvaW50LiAgSWYgdGhlIGdvYWwgaXMgdG8gcHJvdmlkZSBhbiBBS0UsIHRoZW4gYW55IEFLRSB3 aWxsIGRvLiAgSWYgdGhlIGdvYWwgaXMgdG8gY29tbXVuaWNhdGUgd2l0aCBvdGhlciBJbnRlcm5l dCBub2RlcywgdGhlbiB5b3UgbWlnaHQgYXJndWUgdGhhdCBhbnkgQUtFIHdpbGwgZG8sIGJ1dCB5 b3UgYXQgbGVhc3QgaGF2ZSB0byBjb25zaWRlciB3aGF0IGV4aXN0aW5nIEludGVybmV0IG5vZGVz IGRvIGluIG1ha2luZyB0aGF0IGNhbGwuDQoNCltHU10gVGhlc2UgYXJlIGRpZmZlcmVudCBpc3N1 ZXMuIFRoZSBnb2FsIHdpdGggdGhpcyB3b3JrIGlzIHRvIGVuYWJsZSBjb21tdW5pY2F0aW9uIHdp dGggbm9kZXMgaW4gY29uc3RyYWluZWQgbm9kZSBuZXR3b3JrcyBhbmQgdGhlbiBub3QganVzdCBh bnkgQUtFIGlzIGZlYXNpYmxlLiBFeGlzdGluZyBJbnRlcm5ldCBub2RlcyBpbXBsZW1lbnRpbmcg Y3VycmVudCBwcm90b2NvbHMgYXJlIG5vdCBleHBlY3RlZCB0byBzdXBwb3J0IGNvbW11bmljYXRp b24gdG8gdGhlIG1vc3QgY29uc3RyYWluZWQgc2V0dGluZ3MuIFdoYXQgSSB3YW50ZWQgdG8gaGln aGxpZ2h0IHdpdGggbXkgY29tbWVudCBpcyB0aGF0IHRoZSByZWZlcmVuY2UgeW91IHVzZWQgcHJl c3VtZXMgZW5kLXRvLWVuZCBzZWN1cml0eSB0byBjb25zdHJhaW5lZCBub2Rlcywgd2hpY2ggaXMg ZW5hYmxlZCBieSB0aGUgbGlnaHR3ZWlnaHQgQUtFIGlkZW50aWZpZWQgaW4gdGhpcyBkaXNjdXNz aW9uLg0KDQoNCkfDtnJhbg0KICAgIA0KDQo= From nobody Thu Apr 11 07:26:25 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D46120045 for ; Thu, 11 Apr 2019 07:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_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=ihtfp.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 EitifIpUikiO for ; Thu, 11 Apr 2019 07:26:22 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056DE120033 for ; Thu, 11 Apr 2019 07:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B914EE2044 for ; Thu, 11 Apr 2019 10:26:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 01277-10 for ; Thu, 11 Apr 2019 10:26:15 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id C60FCE2042 for ; Thu, 11 Apr 2019 10:26:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1554992775; bh=9b4uN96C0YuI3EoFmD9ryg1vBebvfVatGSA5WULVu1c=; h=From:To:Subject:Date; b=U/6OZHGlBB0LkwyU4lMUdm4sp9SPxW0KuYH2Fs56hfPm+UiwRzXAW0WXY/QJMb88A JRO/sAc+eU+B6G6dWnvQZlaso0Gxy3Z2vI5/UokF7U3irx1WLtB/XDouBAyVjHeZf+ HFb32CiCU8B4Qh7qELTzNKEWqUzxAPEnwApUSd/s= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x3BEQBTx030773; Thu, 11 Apr 2019 10:26:11 -0400 From: Derek Atkins To: secdispatch@ietf.org Date: Thu, 11 Apr 2019 10:26:10 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [Secdispatch] OpenPGP Device Certificates (draft-atkins-openpgp-device-certificates) X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:26:24 -0000 Hi, A few years ago I wrote a draft on how to extend OpenPGP to support third-party certification of IoT devices where the device has only an encryption key (and therefore cannot self-certify). The draft also registers a bunch of notations in order to reduce the size of these certificates when providing ancillary data. The draft was incorporated into RFC4880bis (so there is consensus on progressing the concept) but it is unclear to me when that draft will progress. In the meantime, I would let to get these registered. Therefore, I would like to request AD support in progressing this document, draft-atkins-openpgp-device-certificates. The specific IANA registries affected are a combination of IETF and Expert Review. Thanks for your consideration, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 11 09:17:28 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EA81203AA for ; Thu, 11 Apr 2019 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 e_KPMA3NCblc for ; Thu, 11 Apr 2019 09:17:24 -0700 (PDT) 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 C180312039B for ; Thu, 11 Apr 2019 09:17:23 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id r24so6105228ljg.3 for ; Thu, 11 Apr 2019 09:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iabi9KHpesvehrl69uHNkzr4ER+qQ5e+uPpAsV2Ri9k=; b=hBKALaqICh107HebfBP16ZVIVhBD7EVssOFFtTR6jqYpQ299+n8EBD/4i5jBGj7k6T n+NUOwEhiAUNCYvtoNdoIbB1kgRMbuMYl8wW1nmwgMqz1dSsI1fg1PucGczc7TLGYvSz jqbrPMHTwnmspoOhpoCBziC9nPrTDO+FZmioNtf7PZd5IeJqEaCRODgspOao2ES1pU1f vEDzk9qK88oEaeJ6t0HJgoliWgXC45D7lPoI/+im21h1ZwTi92e7meznMhrtwdE+U1hv gWAhi1JEhSdHrl8qCKSDeEfR9bZvabWJ0ksrb3pDMEeXk6c3G4ZNx5qHWDLGORQTAqkW fo/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Iabi9KHpesvehrl69uHNkzr4ER+qQ5e+uPpAsV2Ri9k=; b=aA/q1Wa468yq/N7oN0in17D8U0OCiA1Eqe16D3thAMpEkM+9TeLzfW9j0z1wyuHdQL crfv6yCs/sMjIFfcxVfgIG0+7jlyTIDXxmNh9FEA6mN0I/OMZWyoPGS6/+SVZyNBuehF uUcPkLKRKOy4SkjnKWnIWaTePxkO4wcTtSCAKaEN3flhcUk/hyVdvkM7aG0/RWndU6Y1 aKSu7GMcw9Xw5c4Xr/xGCwAJ0ASj5Mh6BPjdfkJkYP5ghxdqF5TmYiw61AK3SrSeoQCC FRPPtpraeWVBJZqWMf8Y4w5YL/rvRSTv89Y3pupmBQO7khMO/MBAbGU4BgRe4w0v7KoF 9z6w== X-Gm-Message-State: APjAAAVsYHYFDpm7qZ+zKBFuxLSsJr9+QDnqkDP7zw7Hql7n0HQzIjYk jlHC3VeNudCUSRHKrt6ixcNySqofnAzblTaVODbJPw== X-Google-Smtp-Source: APXvYqyV1tvTO0swSODHBe7H8t93vgcoFcPUdMfCfEvz0KR4b9fO3ynJZEC7QpECJ650oA2/aoXTkuog6Wffz+j3iq0= X-Received: by 2002:a2e:9a49:: with SMTP id k9mr28312734ljj.84.1554999442003; Thu, 11 Apr 2019 09:17:22 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> <9B8B8EDC-354B-44FF-A502-1F40E7FF6946@ericsson.com> In-Reply-To: <9B8B8EDC-354B-44FF-A502-1F40E7FF6946@ericsson.com> From: Eric Rescorla Date: Thu, 11 Apr 2019 09:16:45 -0700 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Cc: Christopher Wood , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005df01a058643851b" Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 16:17:27 -0000 --0000000000005df01a058643851b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2019 at 1:10 AM G=C3=B6ran Selander wrote: > Hi Chris, > > =EF=BB=BFOn 2019-04-10, 03:52, "Secdispatch on behalf of Christopher Wood= " < > secdispatch-bounces@ietf.org on behalf of caw@heapingbits.net> wrote: > > Hi G=C3=B6ran, > > [- - -] > > If what=E2=80=99s missing is a lightweight AKE protocol, then shouldn= =E2=80=99t the > purpose of this WG be to first identify what lightweight means? To > reiterate (my understanding of) Martin=E2=80=99s point, it seems the requ= irements > do not have consensus, and therefore choosing a specific AKE is a bit > premature. It seems prudent to first get a shared understanding of the > problem space and requirements before we trim the solution space. > > [GS:] > > The purpose of the Secdispatch interim meeting on March 05, the preceding > and following discussion was to detail the requirements (and present the > results of the security analysis). Our post-interim compilation of the > usual BoF questions including requirements (and specification of > 'lightweight') is here: > > https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLj= ZGCU > > The security ADs' conclusion of the whole discussion and proposal for nex= t > steps, including a request for community feedback (which ended on Monday) > is here: > > https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjX= Im0c "Thanks for all of the feedback so far. We would appreciate any additional thoughts by Monday, April 15, 2019." It's currently April 11. -Ekr > > I only see a large number of people agreeing and no technical argument > against. > > Apologies for my impatience, but the discussion is over 2 years old. The > people contesting this work has been against it for a long time and the > argument has shifted from "the TLS handshake is lightweight" to "there is > no need for a lightweight handshake" to "OK, we need a lightweight > handshake, but not as lightweight as EDHOC". (The last statement is > slightly distorting the argument, but just to give the idea.) > > G=C3=B6ran > > > Best, > Chris > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000005df01a058643851b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 10, 2019 at 1:10 AM G=C3= =B6ran Selander <goran.se= lander@ericsson.com> wrote:
Hi Chris,

=EF=BB=BFOn 2019-04-10, 03:52, "Secdispatch on behalf of Christopher W= ood" <secdispatch-bounces@ietf.org on behalf of caw@heapingbits.net> wrote:

=C2=A0 =C2=A0 Hi G=C3=B6ran,

[- - -]

=C2=A0 =C2=A0 If what=E2=80=99s missing is a lightweight AKE protocol, then= shouldn=E2=80=99t the purpose of this WG be to first identify what lightwe= ight means? To reiterate (my understanding of) Martin=E2=80=99s point, it s= eems the requirements do not have consensus, and therefore choosing a speci= fic AKE is a bit premature. It seems prudent to first get a shared understa= nding of the problem space and requirements before we trim the solution spa= ce.

[GS:]

The purpose of the Secdispatch interim meeting on March 05, the preceding a= nd following discussion was to detail the requirements (and present the res= ults of the security analysis). Our post-interim compilation of the usual B= oF questions including requirements (and specification of 'lightweight&= #39;) is here:
https://mailarchive.iet= f.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU

The security ADs' conclusion of the whole discussion and proposal for n= ext steps, including a request for community feedback (which ended on Monda= y) is here:
https://mailarchive.iet= f.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c

"Thanks for all of the feedback so far.=C2=A0 We would= appreciate any additional thoughts by Monday, April 15, 2019."
<= div>
It's currently April 11.

-E= kr




I only see a large number of people agreeing and no technical argument agai= nst.

Apologies for my impatience, but the discussion is over 2 years old. The pe= ople contesting this work has been against it for a long time and the argum= ent has shifted from "the TLS handshake is lightweight" to "= there is no need for a lightweight handshake" to "OK, we need a l= ightweight handshake, but not as lightweight as EDHOC". (The last stat= ement is slightly distorting the argument, but just to give the idea.)

G=C3=B6ran


=C2=A0 =C2=A0 Best,
=C2=A0 =C2=A0 Chris

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Secdispatch mailing list
=C2=A0 =C2=A0 Sec= dispatch@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo= /secdispatch


_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000005df01a058643851b-- From nobody Thu Apr 11 10:02:50 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D09F1203D7 for ; Thu, 11 Apr 2019 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dABwQ5hEmKVD for ; Thu, 11 Apr 2019 10:02:46 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1966A1205CC for ; Thu, 11 Apr 2019 10:02:45 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id k21so5901735otf.1 for ; Thu, 11 Apr 2019 10:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O8FZqPCrX1DNhHDYuuQp/YKhPh/KOkjhzN0yLND47l8=; b=TgXCn6qIwb5NWdOFWmnQOZA7ljP/0XC+H5I/0Pd7dB/0CJpXDKZmQgOBPJ+ao1WMNg pP5mMX5w8Q+q8XWLF/TFwDBqjXgwiDAmNkOI32bMIcpEBQqA+3j4DkzuH7owgqai7Ra7 BKsvN7Kr1c784KNkn4MGt5BrxXKg7aognCf7+ASyeagFLxiVhZSZvUGY3l97WkeGL5y+ he3T8dN3hkcbWharhrChNRM+nvqtSQ01b0erx40W33l13YJXiKJfeZo81l0fNxL130EI MNKy85azN1qkSt6lMot//vjd2Qy2zrLhgrH/6Lx57UDyVnqoqFlHtO1dRPFrLtxHPN0v bstQ== 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=O8FZqPCrX1DNhHDYuuQp/YKhPh/KOkjhzN0yLND47l8=; b=kPxJHg7SVgA8SLnIrpzkeM0rek1c/ozUAcaWzObIiZoBPttaW/8c2JPp519xDEgK0W YNEf1wENA8r4rxaBml1Z8UmcT9TPSh1ztIAYxbti/GjSUN1ofM3tQj+CVOhvkLBkQTGf 7kPMF/oRrWV4ouOU6TNiPMl+ruQNaaQYyQ/h+5vUzZx0AgoCzeeCV3KauNKCvTtSRjIE pm4uPmjsyBgT4l362HpzbcE/OaifZAjsJ7n1ZNVszvIIRFx8CAP2f5LF5QP24Yesna+6 gfA6pwnhJ9TvzNaJGZxzz03w1geEb6OJ8WkOs39/NsFi5/N9RJJCuBhvdaf77h74UwRb HpJg== X-Gm-Message-State: APjAAAU7nb41NC9wudzvoOKdIbA5hAVzJ5WopjvaLRbBlEmM5agxfD8m 2LrgH5P67ISuUXgsgtiQOu+1ybZtc9PH9mrHlA9+JhdNtE7Mvw== X-Google-Smtp-Source: APXvYqwhXrs6B3r1ajjJEGBb4N6A2KKqvjDonrNK2sZlk/+CQW4tG6+oLgE33l1889H0PhwTCXQ9lbl5j/+XiY65V+Y= X-Received: by 2002:a9d:27e9:: with SMTP id c96mr33854522otb.206.1555002163978; Thu, 11 Apr 2019 10:02:43 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> From: Richard Barnes Date: Thu, 11 Apr 2019 13:02:26 -0400 Message-ID: To: Roman Danyliw Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009bf78a058644278c" Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 17:02:50 -0000 --0000000000009bf78a058644278c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Sorry for the late-ish reply. I wanted to write some code to confirm my thoughts here and provide some concrete data. tl;dr: * EDHOC is not ALARP, both in the =E2=80=9CAL=E2=80=9D and =E2=80=9CRP=E2= =80=9D senses * TLS, unmodified, can be compressed to within a factor of 2 of EDHOC * TLS can be tweaked to be smaller than EDHOC while making fewer sacrifices cryptographically * For the RPK case, with TLS numbers from implementation, not specification= : * EDHOC =3D (39, 120, 85) * TLS compressed =3D (64, 180, 116) * TLS with similar but smaller sacrifices =3D (32, 113, 81) It=E2=80=99s well-established at this point that EDHOC makes some cryptogra= phic compromises vis =C3=A0 vis TLS that not everyone is comfortable with. Name= ly, (1) it omits the random values sent in the TLS ClientHello and ServerHello messages, and (2) it relies on an AEAD authentication tag in the role that the Finished MAC plays in TLS. The uncertainty around these optimizations raises two questions: 1. How small can a TLS handshake be made *without* making these compromises= ? 2. If we make analogous compromises in TLS, what is the minimum message size? To answer these questions empirically, I made a fork of the mint TLS 1.3 library that implements these modifications for the RPK case. You can see the diff at the following URL; it's about 800 extra LoC: https://github.com/bifurcation/mint/compare/ctls (The PSK case would be straightforward, just didn=E2=80=99t have time.) # Compressing TLS We start from the observation that simply re-encoding TLS messages doesn=E2= =80=99t change the security proofs at all. If the inputs to the cryptographic functions are the same, then you get the same assurances regardless of whether you get them off the wire or prenegotiate them. If you assume, as EDHOC does, that the negotiation bits of TLS can be done out of band, then you can make a compression layer that, on sending, removes all those unnecessary bits, and on receiving, reconstructs the original message using the prenegotiated values. If you do that with the standard TLS mutual-auth handshake, then you arrive at the following message sizes and allocations of bytes: TLS-RPK-ZIP: (64, 180, 116) M1: 32 [rand] + 32 [DH] M2: 32 [rand] + 32 [DH] + 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG] M3: 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG] This seems like a pretty compelling result in itself, since you get the full power of TLS here in terms of assurance =E2=80=94 including things lik= e downgrade protection on however you did the prenegotiation. And you get it all with less than 2x the message size of EDHOC. # Tweaking TLS in Questionable Ways Now let=E2=80=99s consider the EDHOC shortcuts noted above. The removal of= the random values seems more plausible to me, since the DH values contribute fresh randomness anyway. So we can tweak the TLS stack to set the randoms to zero, and we no longer have to send them in our messages: TLS-ZIP-NORAND: (32, 148, 116) M1: 32 [DH] M2: 32 [DH] + 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG] M3: 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG] Already, we=E2=80=99ve surpassed EDHOC on the first message. Removing the = Finished message is dicier, since it introduces the authentication concerns that have been discussed elsewhere. In TLS, we can =E2=80=9Cvirtualize=E2=80=9D= the Finished message; since each side can compute the Finished MAC, they can include it in the key schedule even if it=E2=80=99s not sent. If we do that, then we = end up below EDHOC=E2=80=99s message sizes: TLS-RPK-ZIP-NORAND-VFIN: (32, 113, 81) M1: 32 [DH] M2: 32 [DH] + 1 [CertID] + 64 [SIG] + 16 [TAG] M3: 1 [CertID] + 64 [SIG] + 16 [TAG] This is an interesting structure to compare to EDHOC. First, it=E2=80=99s = notable that we got here with fewer sacrifices than EDHOC. Where EDHOC uses 8-bit tags, we use full-size. And the fact that Finished MACs end up in the key schedule mean that at least the application keys will diverge if the parties disagree. (The things in EDHOC that this TLS variant lacks, like connection IDs, can be added back at similar cost.) Second, this highlights how many bytes EDHOC wastes on framing: EDHOC-RPK: M1: 39 =3D 32 [DH] + 1 [msgType] + 1 [CID] + 2 [ciphers] + 3 [framing] M2: 120 =3D 32 [DH] + 4 [KID] + 64 [SIG] + 8 [TAG] + 2 [CID] + 10 [framing] M3: 85 =3D 4 [KID] + 64 [SIG] + 8 [TAG] + 1 [CID] + 8 [framing] In summary, having taken a pretty deep dive on this problem, it=E2=80=99s n= ot clear at all to me that if you want a lightweight AKE (regardless of the definition of =E2=80=9Clightweight=E2=80=9D) that EDHOC is the best startin= g point. We can get most of the way there just by profiling down TLS, and if we need to go farther, we get more savings with higher assurance by tweaking TLS than we do with a clean-slate design like EDHOC. =E2=80=94Richard On Thu, Mar 28, 2019 at 6:33 AM Roman Danyliw wrote: > Hi! > > We have observed the continued discussion and interest in the topics > discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. Our > assessment of the current state of this discuss and as well as proposed > next steps are below. > > Regards, > Roman and Ben > > [1] > https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZ= trVk > > =3D=3D[ Summary of ADs ]=3D=3D > EDHOC Summary > > -----[ 1. What is the problem we are faced with? > > The community needs an AKE that is 'lightweight' (per slide #3 of [2]) an= d > enables forward security for constrained environments using OSCORE [13]. > 'Lightweight' refers to: > > ** resource consumption, measured by bytes on the wire, wall-clock time t= o > complete (i.e., the initial latency added to application protocols by the > AKE), or power (per slide #12 of [2]) > ** the amount of new code required on end systems which already have an > OSCORE stack [4] > > -----[ 2. Is the problem understood and narrowly scoped? > > Use with OSCORE implicitly assumes that this AKE would support: > ** transport over CoAP, and > ** COSE algorithms > > The specific constrained environments that we are considering use NB-IoT, > 6TiSCH, and LoRaWAN. The desire is to optimize the AKE to be 'as [small] > ... as reasonably achievable' (per [3]) in these environments. > > ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has > already identified the need to "secur[e] the join process and mak[e] that > fit within the constraints of high latency, low throughput and small fram= e > sizes that characterize IEEE802.15.4 TSCH." [12]. > ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG > charter has identified the need to improve the transport capabilities of > LPWA networks such as NB-IoT and LoRa whose "common traits include ... > frame sizes ... [on] the order of tens of bytes transmitted a few times p= er > day at ultra-low speeds" [16]. This indicates IETF interest in supporting > these radio environments, though no security-specific requirements are > included in the charter. > > It may be necessary to evaluate options that make different trade-offs > across a number of dimensions. > > ** Per 'bytes on the wire', it is desirable for these AKE messages to fit > into the MTU size of these protocols; and if not possible, within as few > frames as possible. Note that using multiple MTUs can have significant > costs in terms of time and power (listed below). For 6TiSCH specifically, > as a time-sliced network, this metric (or rather, the quantization into > frame count) is particularly noteworthy, since more frames contribute to > congestion for spectrum (and concomitant error rates) in a non-linear way= , > especially in scenarios when large numbers of independent nodes are > attempting to execute an AKE to join a network. > > ** Per 'time', it is desirable for the AKE message exchange(s) to complet= e > in a reasonable amount of time, both for a single uncongested exchange an= d > when multiple exchanges are running in an interleaved fashion. This > latency may not be a linear function depending on congestion and the > specific radio technology used. For LoRaWAN, which is legally required t= o > use a 1% (or smaller) duty cycle, a payload split into two fragments > instead of one increases the time to complete the sending of this payload > by 10,000% (per slide #10 of [2]). > > ** Per 'power', it is desirable for the transmission of AKE messages and > crypto to draw as little power as possible The best mechanism for doing = so > differs across radio technologies. For example, NB-IoT uses licensed > spectrum and thus can transmit at higher power to improve coverage, makin= g > the transmitted byte count relatively more important than for other radio > technologies. In other cases, the radio transmitter will be active for a > full MTU frame regardless of how much of the frame is occupied by message > content, which makes the byte count less sensitive for the power > consumption. Increased power consumption is unavoidable in poor network > conditions, such as most wide-area settings including LoRaWAN. > > ** Per 'new code', it is desirable to introduce as little new code as > possible onto OSCORE-enabled devices to support this new AKE. These > devices have on the order of 10s of kB of memory and 100s of kB of storag= e > on which an embedded OS; a COAP stack; CORE and AKE libraries; and target > applications would run. It is expected that the majority of this space i= s > available for actual application logic, as opposed to the support librari= es. > > A key question to answer is whether any new solution will reduce these > properties to a sufficient extent to merit investment. > > -----[ 3. Do we believe it is possible to engineer a solution? > > EDHOC [1] appears to be an existence proof that it is possible to produce > an AKE that meaningfully reduces the costs across at least two dimensions > identified in question #1 and 2 (bytes and time). > > EDHOC appears to favorably outperform TLS/CoAP, the current technology, > relative to these dimensions. > > ** Per 'bytes on the wire', MTU sizes and their alignment to the size of > messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and in > [5]. Additional details for 6TiSCH in particular can be found in slide > 36-37 of [2]. > > ** Per 'time', the latency due to back-off time estimates with EDHOC vs. > TLS/CoAP using LoRaWAN can be found in slide #39 of [2] > > ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP using > NB-IoT can be found in slide #35 of [2] > > ** Per 'new code', being able to reuse primitives from the existing COSE > stack is expected to benefit the code size for EDHOC, but no hard data is > yet available for comparison. > > Exploratory work with cTLS [10] and femtoTLS [11] has suggested that > certain optimizations used in EDHOC can also be applied to a > TLS/CoAP-variant. How this impacts the original assumptions and security > analysis for (D)TLS is unknown. > > -----[ 4. Is this particular proposal a good basis for working on? > > EDHOC shows gains in defining an AKE with forward secrecy that is > 'reasonably small[er]' than the baseline of (D)TLS. Specifically, it > appears that EDHOC would enable: > ** for 6TiSCH, a more efficient network join operation, with network join > traffic fitting in one frame per flight (that is, the optimal possible > behavior) in up to a 5-hop network [17] > ** for LoRaWAN, an AKE with forward secrecy that avoids the unacceptable > backoff-induced latency > > A limited interop was performed on draft-selander-ace-cose-ecdhe-05 > (EDHOC) at IETF 98 between [14] and [15]. Despite the inherent challenge= s > of producing a new AKE that is secure, there is reason to have confidence > in the security claims made by EDHOC -- the security properties of -08 we= re > formally verified by [8][9]. Identified issues from this formal analysis > [8] were addressed in -11. The CFRG crypto review panel conducted two > reviews [6][7]. These reviews confirmed that the security claims are > reasonable, attested that the identified issues found in the formal > analysis [8] were fixed, and provided additional recommendations. > > Re-encoding of the TLS handshake as suggested by cTLS [10] may be > possible. However, as of yet, cTLS is an incomplete specification, cTLS > has no formal security analysis, and is technically a new protocol. > > -----[ Conclusion > > There appears to be an understood and scoped problem that is feasible to > engineer. Among the available starting points to address the problem > defined in question #1, EDHOC presents a viable choice. > > Chartering a narrowly scoped, short-lived WG in this space with EDHOC as = a > starting point seems to be an attractive path forward, but we would like = to > receive community feedback on the degree of support for this approach. > > -----[ References > [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt > [2] > https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/material= s/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf > [3] > https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4= Y4lE > [4] > https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wI= Vn_0 > [5] > https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNs= MUlh-k > [6] https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO= 8 > [7] https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eW= Q > [8] https://alessandrobruni.name/papers/18-edhoc.pdf > [9] https://github.com/theisgroenbech/edhoc-proverif > [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 > [11] https://github.com/bifurcation/mint/compare/ftls > [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/ > [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ > [14] https://github.com/alexkrontiris/EDHOC-C > [15] https://github.com/jimsch/EDHOC-csharp > [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/ > [17] > https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-j= oin > > =3D=3D[ End ]=3D=3D > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000009bf78a058644278c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Sorry for the late-ish rep= ly.=C2=A0 I wanted to write some code to confirm my thoughts here and provi= de some concrete data.

tl;dr:
* EDHOC is not ALARP, both in the = =E2=80=9CAL=E2=80=9D and =E2=80=9CRP=E2=80=9D senses
* TLS, unmodified, = can be compressed to within a factor of 2 of EDHOC
* TLS can be tweaked = to be smaller than EDHOC while making fewer sacrifices cryptographically* For the RPK case, with TLS numbers from implementation, not specificatio= n:
=C2=A0=C2=A0=C2=A0 * EDHOC =3D (39, 120, 85)
=C2=A0=C2=A0=C2=A0 * = TLS compressed =3D (64, 180, 116)
=C2=A0=C2=A0=C2=A0 * TLS with similar = but smaller sacrifices =3D (32, 113, 81)

It=E2=80=99s well-establish= ed at this point that EDHOC makes some cryptographic compromises vis =C3=A0= vis TLS that not everyone is comfortable with.=C2=A0 Namely, (1) it omits = the random values sent in the TLS ClientHello and ServerHello messages, and= (2) it relies on an AEAD authentication tag in the role that the Finished = MAC plays in TLS.=C2=A0 The uncertainty around these optimizations raises t= wo questions:

1. How small can a TLS handshake be made *without* mak= ing these compromises?
2. If we make analogous compromises in TLS, what = is the minimum message size?

To answer these questions empirically, = I made a fork of the mint TLS 1.3 library that implements these modificatio= ns for the RPK case.=C2=A0 You can see the diff at the following URL; it= 9;s about 800 extra LoC:


(The PSK case would be straightforward, just didn=E2=80=99t hav= e time.)


# Compressing TLS

We start from the observation= that simply re-encoding TLS messages doesn=E2=80=99t change the security p= roofs at all.=C2=A0 If the inputs to the cryptographic functions are the sa= me, then you get the same assurances regardless of whether you get them off= the wire or prenegotiate them.=C2=A0 If you assume, as EDHOC does, that th= e negotiation bits of TLS can be done out of band, then you can make a comp= ression layer that, on sending, removes all those unnecessary bits, and on = receiving, reconstructs the original message using the prenegotiated values= .

If you do that with the standard TLS mutual-auth handshake, then y= ou arrive at the following message sizes and allocations of bytes:

T= LS-RPK-ZIP: (64, 180, 116)
M1: 32 [rand] + 32 [DH]
M2: 32 [rand] + 32= [DH] + 4 [CertID] + 64 [SIG] + 32 [MAC] + 16 [TAG]
M3: 4 [CertID] + 64 = [SIG] + 32 [MAC] + 16 [TAG]

This seems like a pretty compelling resu= lt in itself, since you get the full power of TLS here in terms of assuranc= e =E2=80=94 including things like downgrade protection on however you did t= he prenegotiation.=C2=A0 And you get it all with less than 2x the message s= ize of EDHOC.


# Tweaking TLS in Questionable Ways

Now let= =E2=80=99s consider the EDHOC shortcuts noted above.=C2=A0 The removal of t= he random values seems more plausible to me, since the DH values contribute= fresh randomness anyway.=C2=A0 So we can tweak the TLS stack to set the ra= ndoms to zero, and we no longer have to send them in our messages:

T= LS-ZIP-NORAND: (32, 148, 116)
M1: 32 [DH]
M2: 32 [DH] + 4 [CertID] + = 64 [SIG] + 32 [MAC] + 16 [TAG]
M3: 4 [CertID] + 64 [SIG] + 32 [MAC] + 16= [TAG]

Already, we=E2=80=99ve surpassed EDHOC on the first message.= =C2=A0 Removing the Finished message is dicier, since it introduces the aut= hentication concerns that have been discussed elsewhere.=C2=A0 In TLS, we c= an =E2=80=9Cvirtualize=E2=80=9D the Finished message; since each side can c= ompute the Finished MAC, they can include it in the key schedule even if it= =E2=80=99s not sent.=C2=A0 If we do that, then we end up below EDHOC=E2=80= =99s message sizes:

TLS-RPK-ZIP-NORAND-VFIN: (32, 113, 81)
M1: 32= [DH]
M2: 32 [DH] + 1 [CertID] + 64 [SIG] + 16 [TAG]
M3: 1 [CertID] += 64 [SIG] + 16 [TAG]

This is an interesting structure to compare to = EDHOC.=C2=A0 First, it=E2=80=99s notable that we got here with fewer sacrif= ices than EDHOC.=C2=A0 Where EDHOC uses 8-bit tags, we use full-size.=C2=A0= And the fact that Finished MACs end up in the key schedule mean that at le= ast the application keys will diverge if the parties disagree.=C2=A0 (The t= hings in EDHOC that this TLS variant lacks, like connection IDs, can be add= ed back at similar cost.)=C2=A0 Second, this highlights how many bytes EDHO= C wastes on framing:

EDHOC-RPK:
M1: 39=C2=A0 =3D 32 [DH] + 1 [msg= Type] + 1 [CID] + 2 [ciphers] + 3 [framing]
M2: 120 =3D 32 [DH] + 4 [KID= ] + 64 [SIG] + 8 [TAG] + 2 [CID] + 10 [framing]
M3: 85=C2=A0 =3D 4 [KID]= + 64 [SIG] + 8 [TAG] + 1 [CID] + 8 [framing]

In summary, having tak= en a pretty deep dive on this problem, it=E2=80=99s not clear at all to me = that if you want a lightweight AKE (regardless of the definition of =E2=80= =9Clightweight=E2=80=9D) that EDHOC is the best starting point.=C2=A0 We ca= n get most of the way there just by profiling down TLS, and if we need to g= o farther, we get more savings with higher assurance by tweaking TLS than w= e do with a clean-slate design like EDHOC.

=E2=80=94Richard

<= br>

On Thu, Mar 28, 2019 at 6:33 AM Roman Danyliw <rdd@cert.org> wrote:
Hi!

We have observed the continued discussion and interest in the topics discus= sed at the March 2019 Virtual Interim Secdispatch meeting [1].=C2=A0 Our as= sessment of the current state of this discuss and as well as proposed next = steps are below.

Regards,
Roman and Ben

[1] https://mailarchive= .ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk

=3D=3D[ Summary of ADs ]=3D=3D
EDHOC Summary

-----[ 1. What is the problem we are faced with?

The community needs an AKE that is 'lightweight' (per slide #3 of [= 2]) and enables forward security for constrained environments using OSCORE = [13].=C2=A0 'Lightweight' refers to:

** resource consumption, measured by bytes on the wire, wall-clock time to = complete (i.e., the initial latency added to application protocols by the A= KE), or power (per slide #12 of [2])
** the amount of new code required on end systems which already have an OSC= ORE stack [4]

-----[ 2. Is the problem understood and narrowly scoped?

Use with OSCORE implicitly assumes that this AKE would support:
** transport over CoAP, and
** COSE algorithms

The specific constrained environments that we are considering use NB-IoT, 6= TiSCH, and LoRaWAN.=C2=A0 The desire is to optimize the AKE to be 'as [= small] ... as reasonably achievable' (per [3]) in these environments.
** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has alre= ady identified the need to "secur[e] the join process and mak[e] that = fit within the constraints of high latency, low throughput and small frame = sizes that characterize IEEE802.15.4 TSCH." [12].
** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG chart= er has identified the need to improve the transport capabilities of LPWA ne= tworks such as NB-IoT and LoRa whose "common traits include ... frame = sizes ... [on] the order of tens of bytes transmitted a few times per day a= t ultra-low speeds" [16]. This indicates IETF interest in supporting t= hese radio environments, though no security-specific requirements are inclu= ded in the charter.

It may be necessary to evaluate options that make different trade-offs acro= ss a number of dimensions.

** Per 'bytes on the wire', it is desirable for these AKE messages = to fit into the MTU size of these protocols; and if not possible, within as= few frames as possible.=C2=A0 Note that using multiple MTUs can have signi= ficant costs in terms of time and power (listed below). For 6TiSCH specific= ally, as a time-sliced network, this metric (or rather, the quantization in= to frame count) is particularly noteworthy, since more frames contribute=C2= =A0 to congestion for spectrum (and concomitant error rates) in a non-linea= r way, especially in scenarios when large numbers of independent nodes are = attempting to execute an AKE to join a network.

** Per 'time', it is desirable for the AKE message exchange(s) to c= omplete in a reasonable amount of time, both for a single uncongested excha= nge and when multiple exchanges are running in an interleaved fashion.=C2= =A0 This latency may not be a linear function depending on congestion and t= he specific radio technology used.=C2=A0 For LoRaWAN, which is legally requ= ired to use a 1% (or smaller) duty cycle, a payload split into two fragment= s instead of one increases the time to complete the sending of this payload= by 10,000% (per slide #10 of [2]).=C2=A0

** Per 'power', it is desirable for the transmission of AKE message= s and crypto to draw as little power as possible=C2=A0 The best mechanism f= or doing so differs across radio technologies.=C2=A0 For example, NB-IoT us= es licensed spectrum and thus can transmit at higher power to improve cover= age, making the transmitted byte count relatively more important than for o= ther radio technologies.=C2=A0 In other cases, the radio transmitter will b= e active for a full MTU frame regardless of how much of the frame is occupi= ed by message content, which makes the byte count less sensitive for the po= wer consumption.=C2=A0 Increased power consumption is unavoidable in poor n= etwork conditions, such as most wide-area settings including LoRaWAN.

** Per 'new code', it is desirable to introduce as little new code = as possible onto OSCORE-enabled devices to support this new AKE.=C2=A0 Thes= e devices have on the order of 10s of kB of memory and 100s of kB of storag= e on which an embedded OS; a COAP stack; CORE and AKE libraries; and target= applications would run.=C2=A0 It is expected that the majority of this spa= ce is=C2=A0 available for actual application logic, as opposed to the suppo= rt libraries.

A key question to answer is whether any new solution will reduce these prop= erties to a sufficient extent to merit investment.

-----[ 3. Do we believe it is possible to engineer a solution?

EDHOC [1] appears to be an existence proof that it is possible to produce a= n AKE that meaningfully reduces the costs across at least two dimensions id= entified in question #1 and 2 (bytes and time).=C2=A0

EDHOC appears to favorably outperform TLS/CoAP, the current technology, rel= ative to these dimensions.

** Per 'bytes on the wire', MTU sizes and their alignment to the si= ze of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and = in [5].=C2=A0 Additional details for 6TiSCH in particular can be found in s= lide 36-37 of [2].

** Per 'time', the latency due to back-off time estimates with EDHO= C vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2]

** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP u= sing NB-IoT can be found in slide #35 of [2]

** Per 'new code', being able to reuse primitives from the existing= COSE stack is expected to benefit the code size for EDHOC, but no hard dat= a is yet available for comparison.=C2=A0

Exploratory work with cTLS [10] and femtoTLS [11] has suggested that certai= n optimizations used in EDHOC can also be applied to a TLS/CoAP-variant.=C2= =A0 How this impacts the original assumptions and security analysis for (D)= TLS is unknown.

-----[ 4. Is this particular proposal a good basis for working on?

EDHOC shows gains in defining an AKE with forward secrecy that is 'reas= onably small[er]' than the baseline of (D)TLS.=C2=A0 Specifically, it a= ppears that EDHOC would enable:
** for 6TiSCH, a more efficient network join operation, with network join t= raffic fitting in one frame per flight (that is, the optimal possible behav= ior) in up to a 5-hop network [17]
** for LoRaWAN, an AKE with forward secrecy that avoids the unacceptable ba= ckoff-induced latency

A limited interop was performed on draft-selander-ace-cose-ecdhe-05 (EDHOC)= at IETF 98 between [14] and [15].=C2=A0 Despite the inherent challenges of= producing a new AKE that is secure, there is reason to have confidence in = the security claims made by EDHOC -- the security properties of -08 were fo= rmally verified by [8][9].=C2=A0 Identified issues from this formal analysi= s [8] were addressed in -11.=C2=A0 The CFRG crypto review panel conducted t= wo reviews [6][7].=C2=A0 These reviews confirmed that the security claims a= re reasonable, attested that the identified issues found in the formal anal= ysis [8] were fixed, and provided additional recommendations.

Re-encoding of the TLS handshake as suggested by cTLS [10] may be possible.= =C2=A0 However, as of yet, cTLS is an incomplete specification, cTLS has no= formal security analysis, and is technically a new protocol.

-----[ Conclusion

There appears to be an understood and scoped problem that is feasible to en= gineer.=C2=A0 Among the available starting points to address the problem de= fined in question #1, EDHOC presents a viable choice.=C2=A0

Chartering a narrowly scoped, short-lived WG in this space with EDHOC as a = starting point seems to be an attractive path forward, but we would like to= receive community feedback on the degree of support for this approach.

-----[ References
[1] https://www.ietf.org/id/draft-seland= er-ace-cose-ecdhe-13.txt
[2] https://datatracker.ietf.org/meeting/interim-2= 019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc= .pdf
[3] https://mailarchive= .ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE
[4] https://mailarchive= .ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0
[5] https://docs.goog= le.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k
[6] https://mailarchive.ietf.o= rg/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8
[7] https://mailarchive.ietf.o= rg/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ
[8] https://alessandrobruni.name/papers/18-edhoc.pdf=
[9] https://github.com/theisgroenbech/edhoc-proverif=
[10] https://tools.ietf.org/html/draft-rescorl= a-tls-ctls-01
[11] https://github.com/bifurcation/mint/compare/ftl= s
[12] https://datatracker.ietf.org/doc/charter-= ietf-6tisch/
[13] https://datatracker.ietf.org/d= oc/draft-ietf-core-object-security/
[14] https://github.com/alexkrontiris/EDHOC-C
[15] https://github.com/jimsch/EDHOC-csharp
[16] https://datatracker.ietf.org/doc/charter-= ietf-lpwan/
[17] https://datatracker= .ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join

=3D=3D[ End ]=3D=3D

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000009bf78a058644278c-- From nobody Thu Apr 11 10:11:06 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B462D1206AA for ; Thu, 11 Apr 2019 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZlSuDW9bRlgW for ; Thu, 11 Apr 2019 10:10:56 -0700 (PDT) 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 90A6F1206C7 for ; Thu, 11 Apr 2019 10:10:55 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id k8so6220656lja.8 for ; Thu, 11 Apr 2019 10:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2SU6j5X9b/QSuRcbEPviTGxABXMxvjBYl4vn5UazAYk=; b=0+E8y0vdb0bBL+QnRXiKebhrN5AB5k7Ex1oicruwjrQAhZPz7W4wEhCfCv19LyXo6/ 01B9nnVX6qNCAnAE8svNc3umzL8SEOl3HEJFa3EaiZmZEQ6qJxNHl9tvLVnorIQDr37m 52wiJFoGjiDbOeoGKWtfjKrkys05ucwtnnIvVZ4kl922cWuh3kmYIvSKrMSkKNQxjZPX aroE6oUuNRvdSy9vlOpPX9pDS8U0+xpe2kCRmAF5kZEuAOB2iwSqdS//zOz/Yx43RoBF OHzy1q/tRduCWrgNBKvnotJQVGi79pS6wR6ZKWqBWRp5e31jFkME+urn0YZj+cHuwNO+ nsJg== 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=2SU6j5X9b/QSuRcbEPviTGxABXMxvjBYl4vn5UazAYk=; b=K3gp9IA2iaTvphB2JXL+ekmcNeo0mq89iPNF5BsLXQUYbgfyZuosihfokOudDgfGGn rfjlb6AZW7UjWWfJlvQNT93u9E4hpPtn79IU291Fdxc5llVNoxZAYipfUYm+KzxlGI5J 9bhh4yWbCeQvRwfltEl1OgJBY4nYXUcE8q1mlsPzIjsC/7KzQm7mJhMZJzDaWndKEPCb tH24lvMjrI2SkaDw1ThVChmdtReKAH2dLZEsTLRqaB44lK0o2sToOS5kY9wxAPu0sp3R zZ/PJKaIJ4B3BPSfoH8FBSG0x2gZ4VWt88iwCowjDN3BCChBzc7utZBLEc5lo1tMue1o HPKQ== X-Gm-Message-State: APjAAAXZl1l2OOQdCUgxge1WB/VfV+uEcRmLff0rcUCF2+StnUCfDyNz uJ8HNqFIglz10egMNnhuMJaPzm/1v9VHQhZ1wmQe1Q== X-Google-Smtp-Source: APXvYqw4HQZdkO5RJOWxZa/wL4xyXnOxKYqVw4E13ADvD3MpyYyuaOxvxHgeGuRUkzBGroflv6EeRPALu1coqjnHuNY= X-Received: by 2002:a2e:808e:: with SMTP id i14mr28648343ljg.103.1555002653417; Thu, 11 Apr 2019 10:10:53 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> From: Eric Rescorla Date: Thu, 11 Apr 2019 10:10:15 -0700 Message-ID: To: Roman Danyliw Cc: "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c838720586444410" Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 17:11:05 -0000 --000000000000c838720586444410 Content-Type: text/plain; charset="UTF-8" Roman, Ben, Thanks for following up on this. I agree with the assessment that it's useful to have a lightweight AKE protocol and that we should initiate some work to deliver that. It seems to me that there are still open questions about: 1. Exactly what the requirements are for lightweight. 2. Whether it's necessary to design a new protocol or whether it is possible to adopt an existing IETF protocol (TLS seems to be the one where there is interest, but IKEv2 or others seem like other potential candidates). Obviously, settling the first quesiton is important to evaluate the second. I've heard a lot of "as light as possible", but that's not operationalizable. The most concrete thing I have seem is Goran's message of March 14, which says: Based on the best current practice AKE protocols and security levels used in the Internet today, certain minimum number of protocol messages and minimum sizes of messages are expected. We estimate lower bounds on messages assuming SIGMA-I, since it is 3-pass and allows traffic data after 1 roundtrip, and since SIGMA is considered a foundation for state-of-the-art AKEs. Using ECC with a security level of 128 bits, the size of ephemeral key and signature are commonly at least 32 and 64 bytes, respectively. MACs used in the constrained setting have a lower bound of 8 bytes. Applying these basic estimates on the SIGMA-I construction for an AKE authenticated with RPK: Message 1: > 32 bytes Message 2: > 104 bytes Message 3: > 72 bytes The corresponding estimates for an AKE authenticated with PSK are: Message 1: > 32 bytes Message 2: > 40 bytes Message 3: > 8 bytes Considering that the maximum message size for avoiding fragmentation is of the order of 50 bytes, for an RPK based AKE it is not possible to send message 2 and 3 in one frame, and not even two frames may be enough for message 2. Taking LoRaWAN as a benchmark, for which available frame size is at most 51 bytes, the lowest number of frames per message to hope for given the assumptions above are for PSK (1,1,1) frames, and for RPK (1,3,2) frames. But this is just backfiguring the requirements from what the crypto technology can support. Instead what needs to happen is that we need to ask what the deployment environment requires. Specifically: - Is it possible to use PSKs or is some sort of public key auth needed - Will public keys be predistributed or do they need to be acquired some how (either out of band or via certs) - What is the cost as a function of message size, # of frames, etc. and hence what the maximum sizes are. For instance, imagine a scenario where you needed to use certificates and in which you couldn't tolerate > 64 bytes in either direction -- it's not clear at least to me that some of these environments don't have exactly this setting -- then I don't believe we know how to do this with existing AKE technology no matter how much we compress. So, in terms of requirements, what's needed here is a document which describes these deployment scenarios, including the questions above, and then produces the requirements. Note that there may be different suites of requirements, e.g., - PSK with message sizes X - RPK with message sizes Y - Certs with message sizes Z And of course, some of these may or may not be possible to achieve or require further sacrifices in order to be achievable (e.g., PFS). Now, it's possible that this document exists, but if it does not, then it needs to be produced and we need to have consensus on it. Otherwise, we're just designing in a vacuum. Once we have consensus on the requirements, then we can ask the question of what the right technical solution is. It seems clear that EDHOC is one potential input, but given that the recent work on slimming down the TLS handshake, it seems quite premature to assume that starting with EDHOC is the best approach. -Ekr On Thu, Mar 28, 2019 at 3:33 AM Roman Danyliw wrote: > Hi! > > We have observed the continued discussion and interest in the topics > discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. Our > assessment of the current state of this discuss and as well as proposed > next steps are below. > > Regards, > Roman and Ben > > [1] > https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk > > ==[ Summary of ADs ]== > EDHOC Summary > > -----[ 1. What is the problem we are faced with? > > The community needs an AKE that is 'lightweight' (per slide #3 of [2]) and > enables forward security for constrained environments using OSCORE [13]. > 'Lightweight' refers to: > > ** resource consumption, measured by bytes on the wire, wall-clock time to > complete (i.e., the initial latency added to application protocols by the > AKE), or power (per slide #12 of [2]) > ** the amount of new code required on end systems which already have an > OSCORE stack [4] > > -----[ 2. Is the problem understood and narrowly scoped? > > Use with OSCORE implicitly assumes that this AKE would support: > ** transport over CoAP, and > ** COSE algorithms > > The specific constrained environments that we are considering use NB-IoT, > 6TiSCH, and LoRaWAN. The desire is to optimize the AKE to be 'as [small] > ... as reasonably achievable' (per [3]) in these environments. > > ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has > already identified the need to "secur[e] the join process and mak[e] that > fit within the constraints of high latency, low throughput and small frame > sizes that characterize IEEE802.15.4 TSCH." [12]. > ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG > charter has identified the need to improve the transport capabilities of > LPWA networks such as NB-IoT and LoRa whose "common traits include ... > frame sizes ... [on] the order of tens of bytes transmitted a few times per > day at ultra-low speeds" [16]. This indicates IETF interest in supporting > these radio environments, though no security-specific requirements are > included in the charter. > > It may be necessary to evaluate options that make different trade-offs > across a number of dimensions. > > ** Per 'bytes on the wire', it is desirable for these AKE messages to fit > into the MTU size of these protocols; and if not possible, within as few > frames as possible. Note that using multiple MTUs can have significant > costs in terms of time and power (listed below). For 6TiSCH specifically, > as a time-sliced network, this metric (or rather, the quantization into > frame count) is particularly noteworthy, since more frames contribute to > congestion for spectrum (and concomitant error rates) in a non-linear way, > especially in scenarios when large numbers of independent nodes are > attempting to execute an AKE to join a network. > > ** Per 'time', it is desirable for the AKE message exchange(s) to complete > in a reasonable amount of time, both for a single uncongested exchange and > when multiple exchanges are running in an interleaved fashion. This > latency may not be a linear function depending on congestion and the > specific radio technology used. For LoRaWAN, which is legally required to > use a 1% (or smaller) duty cycle, a payload split into two fragments > instead of one increases the time to complete the sending of this payload > by 10,000% (per slide #10 of [2]). > > ** Per 'power', it is desirable for the transmission of AKE messages and > crypto to draw as little power as possible The best mechanism for doing so > differs across radio technologies. For example, NB-IoT uses licensed > spectrum and thus can transmit at higher power to improve coverage, making > the transmitted byte count relatively more important than for other radio > technologies. In other cases, the radio transmitter will be active for a > full MTU frame regardless of how much of the frame is occupied by message > content, which makes the byte count less sensitive for the power > consumption. Increased power consumption is unavoidable in poor network > conditions, such as most wide-area settings including LoRaWAN. > > ** Per 'new code', it is desirable to introduce as little new code as > possible onto OSCORE-enabled devices to support this new AKE. These > devices have on the order of 10s of kB of memory and 100s of kB of storage > on which an embedded OS; a COAP stack; CORE and AKE libraries; and target > applications would run. It is expected that the majority of this space is > available for actual application logic, as opposed to the support libraries. > > A key question to answer is whether any new solution will reduce these > properties to a sufficient extent to merit investment. > > -----[ 3. Do we believe it is possible to engineer a solution? > > EDHOC [1] appears to be an existence proof that it is possible to produce > an AKE that meaningfully reduces the costs across at least two dimensions > identified in question #1 and 2 (bytes and time). > > EDHOC appears to favorably outperform TLS/CoAP, the current technology, > relative to these dimensions. > > ** Per 'bytes on the wire', MTU sizes and their alignment to the size of > messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and in > [5]. Additional details for 6TiSCH in particular can be found in slide > 36-37 of [2]. > > ** Per 'time', the latency due to back-off time estimates with EDHOC vs. > TLS/CoAP using LoRaWAN can be found in slide #39 of [2] > > ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP using > NB-IoT can be found in slide #35 of [2] > > ** Per 'new code', being able to reuse primitives from the existing COSE > stack is expected to benefit the code size for EDHOC, but no hard data is > yet available for comparison. > > Exploratory work with cTLS [10] and femtoTLS [11] has suggested that > certain optimizations used in EDHOC can also be applied to a > TLS/CoAP-variant. How this impacts the original assumptions and security > analysis for (D)TLS is unknown. > > -----[ 4. Is this particular proposal a good basis for working on? > > EDHOC shows gains in defining an AKE with forward secrecy that is > 'reasonably small[er]' than the baseline of (D)TLS. Specifically, it > appears that EDHOC would enable: > ** for 6TiSCH, a more efficient network join operation, with network join > traffic fitting in one frame per flight (that is, the optimal possible > behavior) in up to a 5-hop network [17] > ** for LoRaWAN, an AKE with forward secrecy that avoids the unacceptable > backoff-induced latency > > A limited interop was performed on draft-selander-ace-cose-ecdhe-05 > (EDHOC) at IETF 98 between [14] and [15]. Despite the inherent challenges > of producing a new AKE that is secure, there is reason to have confidence > in the security claims made by EDHOC -- the security properties of -08 were > formally verified by [8][9]. Identified issues from this formal analysis > [8] were addressed in -11. The CFRG crypto review panel conducted two > reviews [6][7]. These reviews confirmed that the security claims are > reasonable, attested that the identified issues found in the formal > analysis [8] were fixed, and provided additional recommendations. > > Re-encoding of the TLS handshake as suggested by cTLS [10] may be > possible. However, as of yet, cTLS is an incomplete specification, cTLS > has no formal security analysis, and is technically a new protocol. > > -----[ Conclusion > > There appears to be an understood and scoped problem that is feasible to > engineer. Among the available starting points to address the problem > defined in question #1, EDHOC presents a viable choice. > > Chartering a narrowly scoped, short-lived WG in this space with EDHOC as a > starting point seems to be an attractive path forward, but we would like to > receive community feedback on the degree of support for this approach. > > -----[ References > [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt > [2] > https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf > [3] > https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE > [4] > https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0 > [5] > https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k > [6] https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8 > [7] https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ > [8] https://alessandrobruni.name/papers/18-edhoc.pdf > [9] https://github.com/theisgroenbech/edhoc-proverif > [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 > [11] https://github.com/bifurcation/mint/compare/ftls > [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/ > [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ > [14] https://github.com/alexkrontiris/EDHOC-C > [15] https://github.com/jimsch/EDHOC-csharp > [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/ > [17] > https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join > > ==[ End ]== > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000c838720586444410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roman, Ben,

Thanks for following u= p on this.

I agree with the assessment that it's useful to have = a lightweight
AKE protocol and that we should initiate some work to deli= ver that.
It seems to me that there are still open questions about:
<= br>1. Exactly what the requirements are for lightweight.
2. Whether it&#= 39;s necessary to design a new protocol or whether it
=C2=A0=C2=A0 is po= ssible to adopt an existing IETF protocol (TLS seems to
=C2=A0=C2=A0 be = the one where there is interest, but IKEv2 or others
=C2=A0=C2=A0 seem l= ike other potential candidates).

Obviously, settling the first quesi= ton is important to evaluate
the second. I've heard a lot of "a= s light as possible", but that's
not operationalizable. The mos= t concrete thing I have seem is Goran's
message of March 14, which s= ays:

=C2=A0=C2=A0 Based on the best current practice AKE protocols a= nd security levels
=C2=A0=C2=A0 used in the Internet today, certain mini= mum number of protocol
=C2=A0=C2=A0 messages and minimum sizes of messag= es are expected. We estimate lower
=C2=A0=C2=A0 bounds on messages assum= ing SIGMA-I, since it is 3-pass and allows
=C2=A0=C2=A0 traffic data aft= er 1 roundtrip, and since SIGMA is considered a
=C2=A0=C2=A0 foundation = for state-of-the-art AKEs. Using ECC with a security level
=C2=A0=C2=A0 = of 128 bits, the size of ephemeral key and signature are commonly at
=C2= =A0=C2=A0 least 32 and 64 bytes, respectively. MACs used in the constrained=
=C2=A0=C2=A0 setting have a lower bound of 8 bytes. Applying these basi= c estimates
=C2=A0=C2=A0 on the SIGMA-I construction for an AKE authenti= cated with RPK:
=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 Mes= sage 1: >=C2=A0 32 bytes
=C2=A0=C2=A0 Message 2: > 104 bytes
= =C2=A0=C2=A0 Message 3: >=C2=A0 72 bytes
=C2=A0=C2=A0
=C2=A0=C2= =A0 The corresponding estimates for an AKE authenticated with PSK are:
= =C2=A0=C2=A0
=C2=A0=C2=A0 Message 1: > 32 bytes
=C2=A0=C2=A0 Mess= age 2: > 40 bytes
=C2=A0=C2=A0 Message 3: >=C2=A0 8 bytes
=C2= =A0=C2=A0
=C2=A0=C2=A0 Considering that the maximum message size for av= oiding fragmentation
=C2=A0=C2=A0 is of the order of 50 bytes, for an RP= K based AKE it is not possible
=C2=A0=C2=A0 to send message 2 and 3 in o= ne frame, and not even two frames may be
=C2=A0=C2=A0 enough for message= 2.
=C2=A0=C2=A0
=C2=A0=C2=A0 Taking LoRaWAN as a benchmark, for whi= ch available frame size is at
=C2=A0=C2=A0 most 51 bytes, the lowest num= ber of frames per message to hope for
=C2=A0=C2=A0 given the assumptions= above are for PSK (1,1,1) frames, and for RPK
=C2=A0=C2=A0 (1,3,2) fram= es.

But this is just backfiguring the requirements from what the cry= pto technology
can support. Instead what needs to happen is that we need= to ask what the
deployment environment requires. Specifically:

-= Is it possible to use PSKs or is some sort of public key auth needed
- = Will public keys be predistributed or do they need to be acquired
=C2=A0= some how (either out of band or via certs)
- What is the cost as a func= tion of message size, # of frames, etc.
=C2=A0 and hence what the maximu= m sizes are.

For instance, imagine a scenario where you needed to us= e certificates
and in which you couldn't tolerate > 64 bytes in e= ither direction --
it's not clear at least to me that some of these = environments don't
have exactly this setting -- then I don't bel= ieve we know how to do
this with existing AKE technology no matter how m= uch we compress.

So, in terms of requirements, what's needed her= e is a document which
describes these deployment scenarios, including th= e questions above,
and then produces the requirements. Note that there m= ay be different
suites of requirements, e.g.,

- PSK with message = sizes X
- RPK with message sizes Y
- Certs with message sizes Z
And of course, some of these may or may not be possible to achieve
or = require further sacrifices in order to be achievable (e.g., PFS).

No= w, it's possible that this document exists, but if it does not, thenit needs to be produced and we need to have consensus on
it. Otherwise,= we're just designing in a vacuum.


Once we have consensus on= the requirements, then we can ask the
question of what the right techni= cal solution is. It seems clear that
EDHOC is one potential input, but g= iven that the recent work on
slimming down the TLS handshake, it seems q= uite premature to assume
that starting with EDHOC is the best approach.<= br>
-Ekr



On Thu, Mar 28, 2019 at 3:33 AM Roman Danyliw= <rdd@cert.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi!

We have observed the continued discussion and interest in the topics discus= sed at the March 2019 Virtual Interim Secdispatch meeting [1].=C2=A0 Our as= sessment of the current state of this discuss and as well as proposed next = steps are below.

Regards,
Roman and Ben

[1] https://mailarchive= .ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk

=3D=3D[ Summary of ADs ]=3D=3D
EDHOC Summary

-----[ 1. What is the problem we are faced with?

The community needs an AKE that is 'lightweight' (per slide #3 of [= 2]) and enables forward security for constrained environments using OSCORE = [13].=C2=A0 'Lightweight' refers to:

** resource consumption, measured by bytes on the wire, wall-clock time to = complete (i.e., the initial latency added to application protocols by the A= KE), or power (per slide #12 of [2])
** the amount of new code required on end systems which already have an OSC= ORE stack [4]

-----[ 2. Is the problem understood and narrowly scoped?

Use with OSCORE implicitly assumes that this AKE would support:
** transport over CoAP, and
** COSE algorithms

The specific constrained environments that we are considering use NB-IoT, 6= TiSCH, and LoRaWAN.=C2=A0 The desire is to optimize the AKE to be 'as [= small] ... as reasonably achievable' (per [3]) in these environments.
** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has alre= ady identified the need to "secur[e] the join process and mak[e] that = fit within the constraints of high latency, low throughput and small frame = sizes that characterize IEEE802.15.4 TSCH." [12].
** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG chart= er has identified the need to improve the transport capabilities of LPWA ne= tworks such as NB-IoT and LoRa whose "common traits include ... frame = sizes ... [on] the order of tens of bytes transmitted a few times per day a= t ultra-low speeds" [16]. This indicates IETF interest in supporting t= hese radio environments, though no security-specific requirements are inclu= ded in the charter.

It may be necessary to evaluate options that make different trade-offs acro= ss a number of dimensions.

** Per 'bytes on the wire', it is desirable for these AKE messages = to fit into the MTU size of these protocols; and if not possible, within as= few frames as possible.=C2=A0 Note that using multiple MTUs can have signi= ficant costs in terms of time and power (listed below). For 6TiSCH specific= ally, as a time-sliced network, this metric (or rather, the quantization in= to frame count) is particularly noteworthy, since more frames contribute=C2= =A0 to congestion for spectrum (and concomitant error rates) in a non-linea= r way, especially in scenarios when large numbers of independent nodes are = attempting to execute an AKE to join a network.

** Per 'time', it is desirable for the AKE message exchange(s) to c= omplete in a reasonable amount of time, both for a single uncongested excha= nge and when multiple exchanges are running in an interleaved fashion.=C2= =A0 This latency may not be a linear function depending on congestion and t= he specific radio technology used.=C2=A0 For LoRaWAN, which is legally requ= ired to use a 1% (or smaller) duty cycle, a payload split into two fragment= s instead of one increases the time to complete the sending of this payload= by 10,000% (per slide #10 of [2]).=C2=A0

** Per 'power', it is desirable for the transmission of AKE message= s and crypto to draw as little power as possible=C2=A0 The best mechanism f= or doing so differs across radio technologies.=C2=A0 For example, NB-IoT us= es licensed spectrum and thus can transmit at higher power to improve cover= age, making the transmitted byte count relatively more important than for o= ther radio technologies.=C2=A0 In other cases, the radio transmitter will b= e active for a full MTU frame regardless of how much of the frame is occupi= ed by message content, which makes the byte count less sensitive for the po= wer consumption.=C2=A0 Increased power consumption is unavoidable in poor n= etwork conditions, such as most wide-area settings including LoRaWAN.

** Per 'new code', it is desirable to introduce as little new code = as possible onto OSCORE-enabled devices to support this new AKE.=C2=A0 Thes= e devices have on the order of 10s of kB of memory and 100s of kB of storag= e on which an embedded OS; a COAP stack; CORE and AKE libraries; and target= applications would run.=C2=A0 It is expected that the majority of this spa= ce is=C2=A0 available for actual application logic, as opposed to the suppo= rt libraries.

A key question to answer is whether any new solution will reduce these prop= erties to a sufficient extent to merit investment.

-----[ 3. Do we believe it is possible to engineer a solution?

EDHOC [1] appears to be an existence proof that it is possible to produce a= n AKE that meaningfully reduces the costs across at least two dimensions id= entified in question #1 and 2 (bytes and time).=C2=A0

EDHOC appears to favorably outperform TLS/CoAP, the current technology, rel= ative to these dimensions.

** Per 'bytes on the wire', MTU sizes and their alignment to the si= ze of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and = in [5].=C2=A0 Additional details for 6TiSCH in particular can be found in s= lide 36-37 of [2].

** Per 'time', the latency due to back-off time estimates with EDHO= C vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2]

** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP u= sing NB-IoT can be found in slide #35 of [2]

** Per 'new code', being able to reuse primitives from the existing= COSE stack is expected to benefit the code size for EDHOC, but no hard dat= a is yet available for comparison.=C2=A0

Exploratory work with cTLS [10] and femtoTLS [11] has suggested that certai= n optimizations used in EDHOC can also be applied to a TLS/CoAP-variant.=C2= =A0 How this impacts the original assumptions and security analysis for (D)= TLS is unknown.

-----[ 4. Is this particular proposal a good basis for working on?

EDHOC shows gains in defining an AKE with forward secrecy that is 'reas= onably small[er]' than the baseline of (D)TLS.=C2=A0 Specifically, it a= ppears that EDHOC would enable:
** for 6TiSCH, a more efficient network join operation, with network join t= raffic fitting in one frame per flight (that is, the optimal possible behav= ior) in up to a 5-hop network [17]
** for LoRaWAN, an AKE with forward secrecy that avoids the unacceptable ba= ckoff-induced latency

A limited interop was performed on draft-selander-ace-cose-ecdhe-05 (EDHOC)= at IETF 98 between [14] and [15].=C2=A0 Despite the inherent challenges of= producing a new AKE that is secure, there is reason to have confidence in = the security claims made by EDHOC -- the security properties of -08 were fo= rmally verified by [8][9].=C2=A0 Identified issues from this formal analysi= s [8] were addressed in -11.=C2=A0 The CFRG crypto review panel conducted t= wo reviews [6][7].=C2=A0 These reviews confirmed that the security claims a= re reasonable, attested that the identified issues found in the formal anal= ysis [8] were fixed, and provided additional recommendations.

Re-encoding of the TLS handshake as suggested by cTLS [10] may be possible.= =C2=A0 However, as of yet, cTLS is an incomplete specification, cTLS has no= formal security analysis, and is technically a new protocol.

-----[ Conclusion

There appears to be an understood and scoped problem that is feasible to en= gineer.=C2=A0 Among the available starting points to address the problem de= fined in question #1, EDHOC presents a viable choice.=C2=A0

Chartering a narrowly scoped, short-lived WG in this space with EDHOC as a = starting point seems to be an attractive path forward, but we would like to= receive community feedback on the degree of support for this approach.

-----[ References
[1] https://www.ietf.org/id/draft-seland= er-ace-cose-ecdhe-13.txt
[2] https://datatracker.ietf.org/meeting/interim-2= 019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc= .pdf
[3] https://mailarchive= .ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE
[4] https://mailarchive= .ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0
[5] https://docs.goog= le.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k
[6] https://mailarchive.ietf.o= rg/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8
[7] https://mailarchive.ietf.o= rg/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ
[8] https://alessandrobruni.name/papers/18-edhoc.pdf=
[9] https://github.com/theisgroenbech/edhoc-proverif=
[10] https://tools.ietf.org/html/draft-rescorl= a-tls-ctls-01
[11] https://github.com/bifurcation/mint/compare/ftl= s
[12] https://datatracker.ietf.org/doc/charter-= ietf-6tisch/
[13] https://datatracker.ietf.org/d= oc/draft-ietf-core-object-security/
[14] https://github.com/alexkrontiris/EDHOC-C
[15] https://github.com/jimsch/EDHOC-csharp
[16] https://datatracker.ietf.org/doc/charter-= ietf-lpwan/
[17] https://datatracker= .ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join

=3D=3D[ End ]=3D=3D

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000c838720586444410-- From nobody Thu Apr 11 11:59:23 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45C120380 for ; Thu, 11 Apr 2019 11:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9cl49pLXKuc for ; Thu, 11 Apr 2019 11:59:19 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 525EA12030E for ; Thu, 11 Apr 2019 11:59:19 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id e80so6203217ote.5 for ; Thu, 11 Apr 2019 11:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o8iYGAeaswxySxt5TSWpq2WiUiQ7WyXikoe9wFdN3pI=; b=vdJLEhgWM+QT2dhZVqqvLo9ViV/IVN4a1d62sr+i8nKEC7cccKFFyi5kdcSas3ln0s pxtzRgQCP48VjVDvUbYIpXzxPteSolHV5ENF01vpIYgUa7E8jXxv/w5cY0DRrHTnHk7W Uuwc6WVDAvNCAm0b/64WcsuD4O+Cjs/zLsbQtHmpBhuITIQ9bKLfd37Fg43TGkdZI+/H dU9l5NaO8vGt90TG/Q1AVwYkM/HdAZhnFGFtqCrwv22EeNT4Br7QozGUZTXVpeN7PkmW MkmyTXP6hPtvtlg6lQjyx8Wcb+do8GFMBLShWT+oHGlYdLAGoiscDCcNCF+7jjerkLiN GPzA== 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=o8iYGAeaswxySxt5TSWpq2WiUiQ7WyXikoe9wFdN3pI=; b=Ubf+6rkPyrwav4NCBVfnAloSu7jNqUdS3W0k3UPdmNNBiYSUa2FXuBEDmrte4FQCHO 0yptcJ8ayau/ukhC+2+B26bUoWyJ29/oc5aAawuALumbZgMqZnEiPKv1nvsPNO7V1kF/ wq1V6DgLr1/pu7kz21nZbc8YKQPOmwlXm3bDZ9rojS9AoyzBdF/ois/2TjsAax7oxN7S AOS4fiA9EDn+LhXZKb6AUDIMXE5k2ZeewH2YP4KqotVKKMGvSGe/43TCWckU+8eVI6Jv yQCeDEOz2LCeQQmoUSXuA16vRRdhhx8PLwVdAlclrW6PAS2LIBGv4UGQNA86TpMqza2/ /TEA== X-Gm-Message-State: APjAAAWTk+S6TRObxCvG2LRkAWhC5A7Ip0p4dK54EEaPD94ISasCO5AM k7Smr+A1slL3nUD3Wv1x0QNfNK0/2/TaHOKJeiY1iQ== X-Google-Smtp-Source: APXvYqyEqJYh0QqB2krkqRGadMmyEPgdjNXVJvDwWToHgthi6Z3f0CIVFyKFCLfDRMOWQu9Jdx/hUerHbX1NqxD9/+g= X-Received: by 2002:a9d:27e9:: with SMTP id c96mr34268110otb.206.1555009158593; Thu, 11 Apr 2019 11:59:18 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> In-Reply-To: From: Richard Barnes Date: Thu, 11 Apr 2019 14:59:01 -0400 Message-ID: To: Carsten Bormann Cc: Martin Thomson , =?UTF-8?Q?G=C3=B6ran_Selander?= , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="000000000000855dac058645c8c2" Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 18:59:21 -0000 --000000000000855dac058645c8c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2019 at 3:26 AM Carsten Bormann wrote: > On Apr 10, 2019, at 04:57, Martin Thomson wrote: > > > >> [GS] There is no competing solution to the problem statement. As been > >> witnessed, people have waited for years for this to progress. Therefor= e > >> I don't see anything premature with assuming EDHOC to be a starting > >> point for the WG. > > > > So you would prefer to disregard the work done by Eric and Jim > completely? > > I can=E2=80=99t answer that question for G=C3=B6ran, but personally I rea= lly like that > there are now fresh proposals for addressing TLS handshake size. Those > proposals already do have a natural WG to do the work on them, the TLS WG= , > so no new WG is needed for those; if some rechartering of the TLS WG is > required for that, I=E2=80=99m all for picking up that work there. > > We also need a low-resource authenticated key agreement protocol that we > can use now, and EDHOC is the only one I=E2=80=99m aware of that is in a = stage of > development where it can meet the timelines of the protocols depending on > it. I'd like to push back on this point. It may be that EDHOC has been around for a while and been well-socialized with the IoT crowd, but it is clearly deficient in several other types of maturity, e.g., robustness of formal analyses and state of implementations (AFAICT). --Richard > The main problem that we have had in completing the work was that there > was no WG to assign this work to, and we need to fix this now. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000855dac058645c8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 10, 2019 at 3:26 AM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
On Apr 10, 2019,= at 04:57, Martin Thomson <mt@lowentropy.net> wrote:
>
>> [GS] There is no competing solution to the problem statement. As b= een
>> witnessed, people have waited for years for this to progress. Ther= efore
>> I don't see anything premature with assuming EDHOC to be a sta= rting
>> point for the WG.
>
> So you would prefer to disregard the work done by Eric and Jim complet= ely?

I can=E2=80=99t answer that question for G=C3=B6ran, but personally I reall= y like that there are now fresh proposals for addressing TLS handshake size= .=C2=A0 Those proposals already do have a natural WG to do the work on them= , the TLS WG, so no new WG is needed for those; if some rechartering of the= TLS WG is required for that, I=E2=80=99m all for picking up that work ther= e.

We also need a low-resource authenticated key agreement protocol that we ca= n use now, and EDHOC is the only one I=E2=80=99m aware of that is in a stag= e of development where it can meet the timelines of the protocols depending= on it.=C2=A0

I'd like to push back on= this point.=C2=A0 It may be that EDHOC has been around for a while and bee= n well-socialized with the IoT crowd, but it is clearly deficient in severa= l other types of maturity, e.g., robustness of formal analyses and state of= implementations (AFAICT).

--Richard
=

=C2=A0
The main problem that we have had in completing the work was that th= ere was no WG to assign this work to, and we need to fix this now.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000855dac058645c8c2-- From nobody Thu Apr 11 12:15:05 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A25A120604 for ; Thu, 11 Apr 2019 12:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHq1MKuMAZJn for ; Thu, 11 Apr 2019 12:15:02 -0700 (PDT) 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 3FAFE1205FB for ; Thu, 11 Apr 2019 12:15:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DBE23826C; Thu, 11 Apr 2019 15:14:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7F308708; Thu, 11 Apr 2019 15:15:00 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7CB24479; Thu, 11 Apr 2019 15:15:00 -0400 (EDT) From: Michael Richardson To: Richard Barnes cc: Carsten Bormann , "secdispatch\@ietf.org" , =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FG=3DC3=3DB6ran=5FSelander=3F=3D?= , Martin Thomson In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> 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: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 19:15:04 -0000 --=-=-= Content-Type: text/plain Richard Barnes wrote: > I'd like to push back on this point. It may be that EDHOC has been around for > a while and been well-socialized with the IoT crowd, but it is clearly > deficient in several other types of maturity, e.g., robustness of formal > analyses and state of implementations (AFAICT). I want to be sure that I understand you. Is it your opinion tha the IETF can not form a WG until after a protocol has had formal analysis? How many analysis? How many years? Which publications? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyvkjQACgkQgItw+93Q 3WV/iQf6A8ahUHlscDhV+K7Dw+HHnxY25BqaLBjCpke2O2LnKENzurzUVFRBlUvb wqtICXdDD2ggTtjjES1kRSNfnUOqtoyIoV4WPmwHdoiuSXS0A6UXBIqIVsqHl9QI OXWPnAN+lijPL05i9Jq2TL/M13tpChka0l+ZudP4/IITFBmTWx46MQ4FdfUnc54c 0fJAkXfKPXCI7GIrnhYk7KE1MZUjPaadjlHp1/Rks0KJms+MFQvZHU/k17gbdvXw qPOznA0EENlV6nvqg+pw5Zvj0GHiMrpDuwNEbSmK3f3HYnvhDTsLyn+qwXkfrdn4 65mBQ25M0h+MamtioW1uzhLu7DOlsg== =5fJz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 11 12:20:58 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FFB12060F for ; Thu, 11 Apr 2019 12:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGT6BJkZhHAd for ; Thu, 11 Apr 2019 12:20:54 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 4FFBA120604 for ; Thu, 11 Apr 2019 12:20:54 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id t81so5900310oig.10 for ; Thu, 11 Apr 2019 12:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9E947VIS9N0ApyfqMpLbtz4KgEMQufbGPVKgEAuaWGY=; b=HgzwTUZx4zqIo5DBlHl9VdW20GQ9gyYl19qlv5YgXfh+mUOlpWcuf/pSFYYrMuQE4x RU12ngGt/I3QLmzMxxoySNu83jqsMB+o+5oBlqawc3368NbaYgViwKqEhPgCp3PSgyVu xZosHb7Z+cCKNuaY26NlZJkS/gbaxiRCvQ8gw+py2BwCIZXeikJnlmzpJ3oUqEgRebtZ cWPCE0dwD7WuiTblTZF1ff/3MpXRS3l2FK7CehazuSBRK9c0FM9coDKJoAGaDBGRTXXo E1aa8lo9SWn0Mzx168tvRF8ZBRqLqxJWHlAl6wqv0dsSxWrokfEmn+pH0AMeuwkHm43h LNkg== 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=9E947VIS9N0ApyfqMpLbtz4KgEMQufbGPVKgEAuaWGY=; b=UZEEHYJATLWq1Y9AvnF5sHD/+weUPwMu/5wE0R39EDRtppaiAA978EoSaesUcnuauF G0763QVyELzueMekvl/5oKLZ2/nrqVWB+NjS8TreEULfJ9gCUsrJhfrbXQ/WhjEg4v77 /4PyC5WfwkQRWsAW1VgnDJp0cx0urjilsv1J8/CsGDgKcHSUU3XbCkyt2bSGe7Ha7TG2 aC61sp5Pzaz5PzEipWKSdh6ZpIomvQJRNene4bY3YO715y5vRy+0pIsczDzNV7OTRWv+ xiX0d7xXnA54w45PAH9aazlDPLim77eXNdwrgtWkH7p9QKzyvwBMR17TyjF8nrC1A48v m5hA== X-Gm-Message-State: APjAAAXUegUsb7qjrsu7vswVVtFybetPebUY4VJCwmJwfL4v1IraRFsp wGAboP+Lx5zUtZ9BQ4BocMpyIm9iXqH5wCeAClWGRg== X-Google-Smtp-Source: APXvYqzdrWZXhWvLCEMoXVcnNmCeARxsDeqwn54xtFVfQm3KFFn22n+dTCBvzMG5UNdRBoc7GagseQt8rJ76kzlTwdc= X-Received: by 2002:aca:544b:: with SMTP id i72mr7032688oib.51.1555010453397; Thu, 11 Apr 2019 12:20:53 -0700 (PDT) MIME-Version: 1.0 References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> <3822.1555010100@localhost> In-Reply-To: <3822.1555010100@localhost> From: Richard Barnes Date: Thu, 11 Apr 2019 15:20:35 -0400 Message-ID: To: Michael Richardson Cc: Carsten Bormann , "secdispatch@ietf.org" , =?UTF-8?Q?G=C3=B6ran_Selander?= , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000b27e70058646155a" Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 19:20:57 -0000 --000000000000b27e70058646155a Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 3:15 PM Michael Richardson wrote: > > Richard Barnes wrote: > > I'd like to push back on this point. It may be that EDHOC has been > around for > > a while and been well-socialized with the IoT crowd, but it is > clearly > > deficient in several other types of maturity, e.g., robustness of > formal > > analyses and state of implementations (AFAICT). > > I want to be sure that I understand you. > > Is it your opinion tha the IETF can not form a WG until after a protocol > has > had formal analysis? How many analysis? How many years? Which > publications? > I didn't mean anything w.r.t. the formation of a WG. Carsten's implication seemed to be that an EDHOC WG could deliver more quickly than, e.g., one using TLS as a starting point. That's the point I was pushing back on -- I hope we agree that delivering a final security protocol should be gated on robust analysis and multiple implementations. --Richard > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > --000000000000b27e70058646155a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 11, 2019 at 3:15 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Richard Barnes <rlb@ipv.sx> wrote:
=C2=A0 =C2=A0 > I'd like to push back on this point. It may be that = EDHOC has been around for
=C2=A0 =C2=A0 > a while and been well-socialized with the IoT crowd, but= it is clearly
=C2=A0 =C2=A0 > deficient in several other types of maturity, e.g., robu= stness of formal
=C2=A0 =C2=A0 > analyses and state of implementations (AFAICT).

I want to be sure that I understand you.

Is it your opinion tha the IETF can not form a WG until after a protocol ha= s
had formal analysis?=C2=A0 How many analysis?=C2=A0 How many years?=C2=A0 W= hich publications?

I didn't mean an= ything w.r.t. the formation of a WG.=C2=A0 Carsten's implication seemed= to be that an EDHOC WG could deliver more quickly than, e.g., one using TL= S as a starting point.=C2=A0 That's the point I was pushing back on -- = I hope we agree that delivering a final security protocol should be gated o= n robust analysis and multiple implementations.

--= Richard
=C2=A0

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-
--000000000000b27e70058646155a-- From nobody Thu Apr 11 13:16:10 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464571201CB for ; Thu, 11 Apr 2019 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 SpP18xjHPp7g for ; Thu, 11 Apr 2019 13:16:06 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B666120103 for ; Thu, 11 Apr 2019 13:16:06 -0700 (PDT) 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=YLzV5AxoOs2kA0AG+YNiMHcLjM12C0AC+jl1vkvzuIE=; b=O7WWKKNKh4fEIeNN5gu8PqQi72wgSaUcA9ZRtBIsIn9TxMv0Z9lca5LiOyl++722OVCXYRbHjtQFq57R48I1OEME/uaM5+TUHWt6d3xTe2sB2Mm9TsHXMf75fTPU9nv2vHaugoKeUWKpmhzFoKegJDJY5ALD34ao7kEcXGwJrf0= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3067.eurprd07.prod.outlook.com (10.170.244.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Thu, 11 Apr 2019 20:16:02 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Thu, 11 Apr 2019 20:16:02 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla CC: Christopher Wood , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAJEpqUAAB7BU4AAGO0gAAARaYkAAD8YaYAADIwYgA== Date: Thu, 11 Apr 2019 20:16:02 +0000 Message-ID: <14D57557-7079-4862-9C48-D0AF9901E94E@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> <9B8B8EDC-354B-44FF-A502-1F40E7FF6946@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0763a89-ddf3-4078-90a4-08d6beba851c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3067; x-ms-traffictypediagnostic: HE1PR07MB3067: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(39860400002)(136003)(189003)(199004)(97736004)(316002)(99286004)(186003)(25786009)(11346002)(26005)(486006)(446003)(53936002)(2616005)(6512007)(86362001)(93886005)(36756003)(2906002)(58126008)(3846002)(83716004)(6116002)(54906003)(478600001)(4326008)(6246003)(6506007)(82746002)(33656002)(256004)(476003)(85202003)(14454004)(7736002)(106356001)(102836004)(6916009)(558084003)(229853002)(85182001)(81156014)(68736007)(8676002)(105586002)(305945005)(66066001)(8936002)(71200400001)(71190400001)(6486002)(81166006)(5660300002)(6436002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3067; H:HE1PR07MB4172.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-message-info: XarP+WyH1uNQlLKwt4SUsF/yEm/GXaQQiABZbUFetd6N+J5Vxlr1z1UC6c0V1nAYltvMbY09Vgb29C0UKwb6BwcKEU90WrerraXreMrItmZT5Gpns4i4K3qXEUeMn3Z9WKn0bbhGhTEdm9wcJ/h8oYSxwsl3Z4MdR3oMVtzKZ7mdhalBnAdZQ8PeWJ0NH0JDzk6nfXcS6tMr2GCUCFA/vq35vwzB7NCgB1XqVPw16Htlsxo7iQEwCUBwlJVf7lzGPLFOFNEsVPpGd/974mhZZK9r27JJj5LVMpSxqYciVLZcfBTZeYoyND8FCjSszXJ+QFihuCWiHVAk02AdnEqEC4S2pamoH2S0rhF6tstueTcz68V7wLFHPAJR3VkRlpbMmKMdjIU78s+oDzsApLwSbu/++dSmKQrU17L8ZU0zQL0= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0763a89-ddf3-4078-90a4-08d6beba851c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 20:16:02.4659 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3067 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:16:09 -0000 DQogICAgDQogICAgIlRoYW5rcyBmb3IgYWxsIG9mIHRoZSBmZWVkYmFjayBzbyBmYXIuICBXZSB3 b3VsZCBhcHByZWNpYXRlIGFueSBhZGRpdGlvbmFsIHRob3VnaHRzIGJ5IE1vbmRheSwgQXByaWwg MTUsIDIwMTkuIg0KICAgIA0KICAgIA0KICAgIEl0J3MgY3VycmVudGx5IEFwcmlsIDExLg0KICAg IA0KDQpPb3BzLCB3cm9uZyBNb25kYXkuDQogICAgDQpHw7ZyYW4NCiAgICANCiANCg0KDQo= From nobody Thu Apr 11 14:30:38 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83761120236 for ; Thu, 11 Apr 2019 14:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 hIik8rIx3ZXB for ; Thu, 11 Apr 2019 14:30:31 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80053.outbound.protection.outlook.com [40.107.8.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E7F120220 for ; Thu, 11 Apr 2019 14:30:31 -0700 (PDT) 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=lc88pKN7fm2+2ntWsFcr1oCKRcrt2niOTShGT5557ko=; b=PaKdeOhOv6SRWbe+od3551Z0YuZmXEowIT3oV2fbx8x/N0sa3lEUSjOMoVbs3UcL9O2AbzL8E91F/YxuX686LbfqOTZz8qbsq/WiO2WScn3BoeBoF8P8G/sUUxUjqk8cdOW6ocfiSnSxAhPWOydrm7TCbUlS1WBFx/dfZQgckp4= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4186.eurprd07.prod.outlook.com (20.176.166.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.7; Thu, 11 Apr 2019 21:30:26 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Thu, 11 Apr 2019 21:30:26 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Eric Rescorla , Roman Danyliw CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAALOtV6AAA1GzgA= Date: Thu, 11 Apr 2019 21:30:25 +0000 Message-ID: <8BDC5BE3-997D-433C-9BE7-3FA98ABC4C88@ericsson.com> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0078ac9a-895b-4a27-1276-08d6bec4e9ae x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4186; x-ms-traffictypediagnostic: HE1PR07MB4186: x-ms-exchange-purlcount: 21 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(39860400002)(376002)(346002)(189003)(199004)(78114003)(36756003)(33656002)(106356001)(30864003)(97736004)(99286004)(76176011)(7736002)(6512007)(6246003)(26005)(2906002)(6506007)(25786009)(14454004)(966005)(6306002)(256004)(68736007)(305945005)(14444005)(6486002)(53946003)(229853002)(186003)(561944003)(6436002)(478600001)(102836004)(486006)(11346002)(446003)(53936002)(410100003)(2616005)(81156014)(105586002)(110136005)(5660300002)(58126008)(4326008)(53546011)(86362001)(8936002)(81166006)(8676002)(71200400001)(85202003)(82746002)(83716004)(316002)(476003)(3846002)(71190400001)(66574012)(85182001)(66066001)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4186; H:HE1PR07MB4172.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-message-info: vgXQz6grPcPRqi7/WircLCFc/51MPHVCj/kREBw1jqlzOZh6LGAdQ8SXH5Zer+RNNX6+ccCRjx43sQk8HGR60QDhIiKi0unWFv1ROC8Ts2SvbqUG96w8tUHg/x1MwtdpCTCQOwmkCRh4NfMPm2NZecXoSfGvKFNmx/+I3d5y1TbXQYhyQoJnnq1zSPya83xaxsjd3cdl/GceBnHd9euyJXsUq+XMiER9VsMtWksLZTNZkwSKYFLQJs2f26pqoq/qVg8EbcmPYOUcKjJ9qFqYcUz4Oz2ZLAieDMtRPf1r+DgCkOt0il34v0bTSuY9gYHQ4iKxh07Avw6JW9kQHCFdIm9r6RbquKuqFqn2p5VgiSvqEdjZ6deqzPcuw7r+I2OrO7qTUUFyP41vMV1FVj2rBpkbg2VCUUW6VnrThDE8bgE= Content-Type: text/plain; charset="utf-8" Content-ID: <52F736F34828B54A9E03033705376A57@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0078ac9a-895b-4a27-1276-08d6bec4e9ae X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 21:30:26.1129 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4186 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 21:30:36 -0000 SGkgRWtyLA0KDQpJIGJlbGlldmUgd2UgaGF2ZSBjb3ZlcmVkIHlvdXIgcXVlc3Rpb25zIGluIHRo ZSBwcmV2aW91cyBkaXNjdXNzaW9uLCBoZXJlIGlzIGEgc2hvcnQgc3VtbWFyeS4gDQoNCu+7v09u IDIwMTktMDQtMTEsIDE5OjExLCAiU2VjZGlzcGF0Y2ggb24gYmVoYWxmIG9mIEVyaWMgUmVzY29y bGEiIDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBla3JAcnRmbS5j b20+IHdyb3RlOg0KDQogICAgUm9tYW4sIEJlbiwNCiAgICANCiAgICBUaGFua3MgZm9yIGZvbGxv d2luZyB1cCBvbiB0aGlzLg0KICAgIA0KICAgIEkgYWdyZWUgd2l0aCB0aGUgYXNzZXNzbWVudCB0 aGF0IGl0J3MgdXNlZnVsIHRvIGhhdmUgYSBsaWdodHdlaWdodA0KICAgIEFLRSBwcm90b2NvbCBh bmQgdGhhdCB3ZSBzaG91bGQgaW5pdGlhdGUgc29tZSB3b3JrIHRvIGRlbGl2ZXIgdGhhdC4NCiAg ICBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJlIGFyZSBzdGlsbCBvcGVuIHF1ZXN0aW9ucyBhYm91 dDoNCiAgICANCiAgICAxLiBFeGFjdGx5IHdoYXQgdGhlIHJlcXVpcmVtZW50cyBhcmUgZm9yIGxp Z2h0d2VpZ2h0Lg0KDQpbR1NdIDJiIGFuZCAyYyBwcm92aWRlcyB0aGUgc2V0dGluZzoNCmh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2VjZGlzcGF0Y2gvdk5SN25UMjBmc3ZZ allYaEFQak9wTGpaR0NVDQpTaW5jZSB0aGVyZSBhcmUgZGlmZmVyZW50IHRlY2hub2xvZ2llcyBh bmQgZGlmZmVyZW50IGRlcGxveW1lbnQgc2V0dGluZ3MsIGl0IGlzIG5vdCBleHBlY3RlZCB0byBn ZXQgZXhhY3QgY29kZSBzaXplcyBvciBwb3dlciBjb25zdW1wdGlvbiwgZm9yIGV4YW1wbGUuIE5l dmVydGhlbGVzcyBzcGVjaWZpYyBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHRlY2hub2xvZ2llcyBn aXZlIGRpc3RpbmN0IHBlcmZvcm1hbmNlIGRpZmZlcmVuY2VzIGFzIGlzIGNhcHR1cmVkIGJ5IHRo ZSBiZW5jaG1hcmtzLg0KDQogICAgMi4gV2hldGhlciBpdCdzIG5lY2Vzc2FyeSB0byBkZXNpZ24g YSBuZXcgcHJvdG9jb2wgb3Igd2hldGhlciBpdA0KICAgICAgIGlzIHBvc3NpYmxlIHRvIGFkb3B0 IGFuIGV4aXN0aW5nIElFVEYgcHJvdG9jb2wgKFRMUyBzZWVtcyB0bw0KICAgICAgIGJlIHRoZSBv bmUgd2hlcmUgdGhlcmUgaXMgaW50ZXJlc3QsIGJ1dCBJS0V2MiBvciBvdGhlcnMNCiAgICAgICBz ZWVtIGxpa2Ugb3RoZXIgcG90ZW50aWFsIGNhbmRpZGF0ZXMpLg0KDQogICAgT2J2aW91c2x5LCBz ZXR0bGluZyB0aGUgZmlyc3QgcXVlc2l0b24gaXMgaW1wb3J0YW50IHRvIGV2YWx1YXRlDQogICAg dGhlIHNlY29uZC4gSSd2ZSBoZWFyZCBhIGxvdCBvZiAiYXMgbGlnaHQgYXMgcG9zc2libGUiLCBi dXQgdGhhdCdzDQogICAgbm90IG9wZXJhdGlvbmFsaXphYmxlLiBUaGUgbW9zdCBjb25jcmV0ZSB0 aGluZyBJIGhhdmUgc2VlbSBpcyBHb3JhbidzDQogICAgbWVzc2FnZSBvZiBNYXJjaCAxNCwgd2hp Y2ggc2F5czoNCiAgICANCiAgICAgICBCYXNlZCBvbiB0aGUgYmVzdCBjdXJyZW50IHByYWN0aWNl IEFLRSBwcm90b2NvbHMgYW5kIHNlY3VyaXR5IGxldmVscw0KICAgICAgIHVzZWQgaW4gdGhlIElu dGVybmV0IHRvZGF5LCBjZXJ0YWluIG1pbmltdW0gbnVtYmVyIG9mIHByb3RvY29sDQogICAgICAg bWVzc2FnZXMgYW5kIG1pbmltdW0gc2l6ZXMgb2YgbWVzc2FnZXMgYXJlIGV4cGVjdGVkLiBXZSBl c3RpbWF0ZSBsb3dlcg0KICAgICAgIGJvdW5kcyBvbiBtZXNzYWdlcyBhc3N1bWluZyBTSUdNQS1J LCBzaW5jZSBpdCBpcyAzLXBhc3MgYW5kIGFsbG93cw0KICAgICAgIHRyYWZmaWMgZGF0YSBhZnRl ciAxIHJvdW5kdHJpcCwgYW5kIHNpbmNlIFNJR01BIGlzIGNvbnNpZGVyZWQgYQ0KICAgICAgIGZv dW5kYXRpb24gZm9yIHN0YXRlLW9mLXRoZS1hcnQgQUtFcy4gVXNpbmcgRUNDIHdpdGggYSBzZWN1 cml0eSBsZXZlbA0KICAgICAgIG9mIDEyOCBiaXRzLCB0aGUgc2l6ZSBvZiBlcGhlbWVyYWwga2V5 IGFuZCBzaWduYXR1cmUgYXJlIGNvbW1vbmx5IGF0DQogICAgICAgbGVhc3QgMzIgYW5kIDY0IGJ5 dGVzLCByZXNwZWN0aXZlbHkuIE1BQ3MgdXNlZCBpbiB0aGUgY29uc3RyYWluZWQNCiAgICAgICBz ZXR0aW5nIGhhdmUgYSBsb3dlciBib3VuZCBvZiA4IGJ5dGVzLiBBcHBseWluZyB0aGVzZSBiYXNp YyBlc3RpbWF0ZXMNCiAgICAgICBvbiB0aGUgU0lHTUEtSSBjb25zdHJ1Y3Rpb24gZm9yIGFuIEFL RSBhdXRoZW50aWNhdGVkIHdpdGggUlBLOg0KICAgICAgIA0KICAgICAgICANCiAgICAgICBNZXNz YWdlIDE6ID4gIDMyIGJ5dGVzDQogICAgICAgTWVzc2FnZSAyOiA+IDEwNCBieXRlcw0KICAgICAg IE1lc3NhZ2UgMzogPiAgNzIgYnl0ZXMNCiAgICAgICANCiAgICAgICBUaGUgY29ycmVzcG9uZGlu ZyBlc3RpbWF0ZXMgZm9yIGFuIEFLRSBhdXRoZW50aWNhdGVkIHdpdGggUFNLIGFyZToNCiAgICAg ICANCiAgICAgICBNZXNzYWdlIDE6ID4gMzIgYnl0ZXMNCiAgICAgICBNZXNzYWdlIDI6ID4gNDAg Ynl0ZXMNCiAgICAgICBNZXNzYWdlIDM6ID4gIDggYnl0ZXMNCiAgICAgICANCiAgICAgICBDb25z aWRlcmluZyB0aGF0IHRoZSBtYXhpbXVtIG1lc3NhZ2Ugc2l6ZSBmb3IgYXZvaWRpbmcgZnJhZ21l bnRhdGlvbg0KICAgICAgIGlzIG9mIHRoZSBvcmRlciBvZiA1MCBieXRlcywgZm9yIGFuIFJQSyBi YXNlZCBBS0UgaXQgaXMgbm90IHBvc3NpYmxlDQogICAgICAgdG8gc2VuZCBtZXNzYWdlIDIgYW5k IDMgaW4gb25lIGZyYW1lLCBhbmQgbm90IGV2ZW4gdHdvIGZyYW1lcyBtYXkgYmUNCiAgICAgICBl bm91Z2ggZm9yIG1lc3NhZ2UgMi4NCiAgICAgICANCiAgICAgICBUYWtpbmcgTG9SYVdBTiBhcyBh IGJlbmNobWFyaywgZm9yIHdoaWNoIGF2YWlsYWJsZSBmcmFtZSBzaXplIGlzIGF0DQogICAgICAg bW9zdCA1MSBieXRlcywgdGhlIGxvd2VzdCBudW1iZXIgb2YgZnJhbWVzIHBlciBtZXNzYWdlIHRv IGhvcGUgZm9yDQogICAgICAgZ2l2ZW4gdGhlIGFzc3VtcHRpb25zIGFib3ZlIGFyZSBmb3IgUFNL ICgxLDEsMSkgZnJhbWVzLCBhbmQgZm9yIFJQSw0KICAgICAgICgxLDMsMikgZnJhbWVzLg0KICAg IA0KICAgIEJ1dCB0aGlzIGlzIGp1c3QgYmFja2ZpZ3VyaW5nIHRoZSByZXF1aXJlbWVudHMgZnJv bSB3aGF0IHRoZSBjcnlwdG8gdGVjaG5vbG9neQ0KICAgIGNhbiBzdXBwb3J0LiBJbnN0ZWFkIHdo YXQgbmVlZHMgdG8gaGFwcGVuIGlzIHRoYXQgd2UgbmVlZCB0byBhc2sgd2hhdCB0aGUNCiAgICBk ZXBsb3ltZW50IGVudmlyb25tZW50IHJlcXVpcmVzLiANCg0KW0dTXSBJJ20gbm90IHN1cmUgSSB1 bmRlcnN0YW5kIHRoZSBwcm9ibGVtLiBMb1JhV0FOIGRlcGxveW1lbnQgcmVxdWlyZXMgbWluaW1p emluZyB0aW1lLW9uLWFpciBhbmQgbGF0ZW5jeSB3aGljaCBpbXBsaWVzIGFzIGZldyBmcmFtZXMg YXMgcG9zc2libGUuICgxLDEsMSkgaXMgY2xlYXJseSBvcHRpbWFsIGJ1dCBpcyBpbXBvc3NpYmxl IHdpdGggNTEgYnl0ZSBmcmFtZXMgZm9yIFJQSyBtZXNzYWdlIDIgYW5kIDMgd2l0aCB0aGUgU2ln bWEtSSBiYXNlZCBwcm90b2NvbCBhbmQgRUNDIGNyeXB0byB1c2VkIGluIFRMUyBhbmQgRURIT0Mu IA0KDQoNClNwZWNpZmljYWxseToNCiAgICANCiAgICAtIElzIGl0IHBvc3NpYmxlIHRvIHVzZSBQ U0tzIG9yIGlzIHNvbWUgc29ydCBvZiBwdWJsaWMga2V5IGF1dGggbmVlZGVkDQoNCltHU10gWWVz IGl0IGlzIHBvc3NpYmxlLCB0aGlzIGlzIHRoZSBleHBlY3RlZCBkZXBsb3ltZW50IGluIG1hbnkg c2V0dGluZ3MuIA0KDQogICAgLSBXaWxsIHB1YmxpYyBrZXlzIGJlIHByZWRpc3RyaWJ1dGVkIG9y IGRvIHRoZXkgbmVlZCB0byBiZSBhY3F1aXJlZA0KICAgICAgc29tZSBob3cgKGVpdGhlciBvdXQg b2YgYmFuZCBvciB2aWEgY2VydHMpDQoNCltHU10gQm90aCBvcHRpb25zIGFyZSByZWxldmFudCwg YnV0IGNvbnNpZGVyaW5nIHRoYXQgdGhlIHdvcmsgb24gb3B0aW1pemluZyBjZXJ0aWZpY2F0ZSBz aXplIGhhcyBqdXN0IHN0YXJ0ZWQgdGhlIG1vc3QgY29uY3JldGUgc2l6ZSBlc3RpbWF0ZXMgYXJl IGV4cGVjdGVkIHdpdGggcHJlZGlzdHJpYnV0ZWQgUlBLIChvciBQU0spLg0KDQogICAgLSBXaGF0 IGlzIHRoZSBjb3N0IGFzIGEgZnVuY3Rpb24gb2YgbWVzc2FnZSBzaXplLCAjIG9mIGZyYW1lcywg ZXRjLg0KICAgICAgYW5kIGhlbmNlIHdoYXQgdGhlIG1heGltdW0gc2l6ZXMgYXJlLg0KDQpbR1Nd IFRoaXMgZGVwZW5kcyBvbiB0aGUgdGVjaG5vbG9naWVzIHVzZWQuIFRocmVlIHRlY2hub2xvZ2ll cyB3aGljaCBhcmUgaGlnaGx5IHJlbGV2YW50IGZvciBPU0NPUkUgYXJlIE5CLUlvVCwgNlRpU0NI IGFuZCBMb1JhV0FOLiBEZXNjcmliaW5nIGFsbCBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlc2UgdGVj aG5vbG9naWVzIGlzIG5vdCBmZWFzaWJsZSwgc28gb24gcmVxdWVzdCB3ZSBwcmVzZW50ZWQgdGhy ZWUgYmVuY2htYXJrcy4gVGhlIHBlb3BsZSB3aG8gZGVwbG95IHRoZXNlIG5ldHdvcmtzIGhhdmUg Y29uZmlybWVkIHRoYXQgdGhlIGJlbmNobWFya3MgcHJlc2VudGVkIGhlcmUgYXJlIHRoZSByZWxl dmFudCBvbmVzIHNvIHRoZSBsaWdodHdlaWdodCByZXF1aXJlbWVudHMgaW5jbHVkZSB0byBwZXJm b3JtIHdlbGwgd2l0aCByZXNwZWN0IHRvIHRoZXNlIGJlbmNobWFya3MuDQoNCg0KICAgIEZvciBp bnN0YW5jZSwgaW1hZ2luZSBhIHNjZW5hcmlvIHdoZXJlIHlvdSBuZWVkZWQgdG8gdXNlIGNlcnRp ZmljYXRlcw0KICAgIGFuZCBpbiB3aGljaCB5b3UgY291bGRuJ3QgdG9sZXJhdGUgPiA2NCBieXRl cyBpbiBlaXRoZXIgZGlyZWN0aW9uIC0tDQogICAgaXQncyBub3QgY2xlYXIgYXQgbGVhc3QgdG8g bWUgdGhhdCBzb21lIG9mIHRoZXNlIGVudmlyb25tZW50cyBkb24ndA0KICAgIGhhdmUgZXhhY3Rs eSB0aGlzIHNldHRpbmcgLS0gdGhlbiBJIGRvbid0IGJlbGlldmUgd2Uga25vdyBob3cgdG8gZG8N CiAgICB0aGlzIHdpdGggZXhpc3RpbmcgQUtFIHRlY2hub2xvZ3kgbm8gbWF0dGVyIGhvdyBtdWNo IHdlIGNvbXByZXNzLg0KDQpbR1NdIEFzIGFib3ZlLCBMb1JhV0FOIHdpdGggNTEgYnl0ZXMgcGFj a2V0IHNpemUgaXMgb25lIGV4YW1wbGUgb2YgdGhhdC4gSW4gcHJhY3RpY2UsIGZyYWdtZW50YXRp b24gc2NoZW1lcyBhcmUgdXNlZCwgYnV0IHdpdGggdGhlIHBlbmFsdHkgb2YgbGF0ZW5jeSBkdWUg dG8gZHV0eSBjeWNsZSBhbmQgb3RoZXIgcGVyZm9ybWFuY2UgZGVncmFkYXRpb24gZHVlIHRvIHNl bmRpbmcgbXVsdGlwbGUgcGFja2V0cy4gU28gYW4gb3B0aW1hbCBzb2x1dGlvbiBpcyBmb3IgdGhl IG1lc3NhZ2UgdG8gYXZvaWQgYmVpbmcgZnJhZ21lbnRlZCwgb3IgYmVpbmcgc3BsaXQgaW50byBh cyBmZXcgZnJhZ21lbnRzIGFzIHBvc3NpYmxlLiANCg0KICAgIFNvLCBpbiB0ZXJtcyBvZiByZXF1 aXJlbWVudHMsIHdoYXQncyBuZWVkZWQgaGVyZSBpcyBhIGRvY3VtZW50IHdoaWNoDQogICAgZGVz Y3JpYmVzIHRoZXNlIGRlcGxveW1lbnQgc2NlbmFyaW9zLCBpbmNsdWRpbmcgdGhlIHF1ZXN0aW9u cyBhYm92ZSwNCiAgICBhbmQgdGhlbiBwcm9kdWNlcyB0aGUgcmVxdWlyZW1lbnRzLiBOb3RlIHRo YXQgdGhlcmUgbWF5IGJlIGRpZmZlcmVudA0KICAgIHN1aXRlcyBvZiByZXF1aXJlbWVudHMsIGUu Zy4sDQogICAgDQogICAgLSBQU0sgd2l0aCBtZXNzYWdlIHNpemVzIFgNCiAgICAtIFJQSyB3aXRo IG1lc3NhZ2Ugc2l6ZXMgWQ0KICAgIC0gQ2VydHMgd2l0aCBtZXNzYWdlIHNpemVzIFoNCg0KICAg IEFuZCBvZiBjb3Vyc2UsIHNvbWUgb2YgdGhlc2UgbWF5IG9yIG1heSBub3QgYmUgcG9zc2libGUg dG8gYWNoaWV2ZQ0KICAgIG9yIHJlcXVpcmUgZnVydGhlciBzYWNyaWZpY2VzIGluIG9yZGVyIHRv IGJlIGFjaGlldmFibGUgKGUuZy4sIFBGUykuDQogICAgDQogICAgTm93LCBpdCdzIHBvc3NpYmxl IHRoYXQgdGhpcyBkb2N1bWVudCBleGlzdHMsIGJ1dCBpZiBpdCBkb2VzIG5vdCwgdGhlbg0KICAg IGl0IG5lZWRzIHRvIGJlIHByb2R1Y2VkIGFuZCB3ZSBuZWVkIHRvIGhhdmUgY29uc2Vuc3VzIG9u DQogICAgaXQuIE90aGVyd2lzZSwgd2UncmUganVzdCBkZXNpZ25pbmcgaW4gYSB2YWN1dW0uDQog ICAgDQogICAgT25jZSB3ZSBoYXZlIGNvbnNlbnN1cyBvbiB0aGUgcmVxdWlyZW1lbnRzLCB0aGVu IHdlIGNhbiBhc2sgdGhlDQogICAgcXVlc3Rpb24gb2Ygd2hhdCB0aGUgcmlnaHQgdGVjaG5pY2Fs IHNvbHV0aW9uIGlzLiBJdCBzZWVtcyBjbGVhciB0aGF0DQogICAgRURIT0MgaXMgb25lIHBvdGVu dGlhbCBpbnB1dCwgYnV0IGdpdmVuIHRoYXQgdGhlIHJlY2VudCB3b3JrIG9uDQogICAgc2xpbW1p bmcgZG93biB0aGUgVExTIGhhbmRzaGFrZSwgaXQgc2VlbXMgcXVpdGUgcHJlbWF0dXJlIHRvIGFz c3VtZQ0KICAgIHRoYXQgc3RhcnRpbmcgd2l0aCBFREhPQyBpcyB0aGUgYmVzdCBhcHByb2FjaC4N Cg0KW0dTXSBUaGUgTG9SYVdBTiBhbmQgNlRpU0NIIGJlbmNobWFya3MgYm90aCBkZW1vbnN0cmF0 ZSB0aGUgcGVuYWx0eSBvZiBub3QgZml0dGluZyBpbnRvIGZyYW1lcyBvZiB0aGUgb3JkZXIgb2Yg NTAgYnl0ZXMuIEFzIGZhciBhcyBJIGhhdmUgc2VlbiBpbiB0ZXJtcyBvZiBzcGVjaWZpY2F0aW9u cywgdGhlIHJlZHVjdGlvbnMgb2YgdGhlIFRMUyBoYW5kc2hha2UgZG9lcyBub3QgZml0IGludG8g dGhlIG1pbmltdW0gbnVtYmVyIG9mIGZyYW1lcy4gDQoNCkFzIG1lbnRpb25lZCBhYm92ZSwgdGhl IGxpZ2h0d2VpZ2h0IHByb3BlcnRpZXMgYXJlIGNoYXJhY3Rlcml6ZWQgYnkgdGhlIGJlbmNobWFy a3Mgd2hpY2ggYXJlIHByb3ZpZGVkIGJ5IHBlb3BsZSBkZXBsb3lpbmcgdGhlIHRlY2hub2xvZ3ku IEluIGFkZGl0aW9uIHRvIHRoZSBsaWdodHdlaWdodCByZXF1aXJlbWVudHMsIHRoZSByZW1haW5p bmcgcmVxdWlyZW1lbnRzIGNvbWVzIGZyb20gYmVpbmcgYW4gQUtFIGZvciBPU0NPUkU6DQooc2Vl IDJhIG9mIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2VjZGlzcGF0Y2gv dk5SN25UMjBmc3ZZallYaEFQak9wTGpaR0NVKQ0KDQoiQXQgdGhlIGVuZCBvZiB0aGUgQUtFIHRo ZSB0d28gcGFydGllcyBzaG91bGQgaGF2ZSBhZ3JlZWQgb246DQotIGEgc2hhcmVkIHNlY3JldCAo T1NDT1JFIE1hc3RlciBTZWNyZXQpIHdpdGggUEZTIGFuZCBhIGdvb2QgYW1vdW50IG9mIHJhbmRv bW5lc3MNCi0gaWRlbnRpZmllcnMgcHJvdmlkaW5nIGEgaGludCB0byB0aGUgcmVjZWl2ZXIgb2Yg d2hhdCBzZWN1cml0eSBjb250ZXh0IGl0IHNob3VsZCB1c2Ugd2hlbiBkZWNyeXB0aW5nIHRoZSBt ZXNzYWdlIChPU0NPUkUgU2VuZGVyIElEcyBvZiBwZWVyIGVuZHBvaW50cyksIGFyYml0cmFyaWx5 IHNob3J0DQotIENPU0UgYWxnb3JpdGhtcyB0byB1c2Ugd2l0aCBPU0NPUkUNCg0KVGhlIEFLRSBz aG91bGQgc3VwcG9ydCB0aGUgc2FtZSB0cmFuc3BvcnQgYXMgT1NDT1JFIChDb0FQIG92ZXIgZm9v KS4iDQoNCkfDtnJhbg0KDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAg T24gVGh1LCBNYXIgMjgsIDIwMTkgYXQgMzozMyBBTSBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5v cmc+IHdyb3RlOg0KICAgIA0KICAgIA0KICAgIEhpIQ0KICAgIA0KICAgIFdlIGhhdmUgb2JzZXJ2 ZWQgdGhlIGNvbnRpbnVlZCBkaXNjdXNzaW9uIGFuZCBpbnRlcmVzdCBpbiB0aGUgdG9waWNzIGRp c2N1c3NlZCBhdCB0aGUgTWFyY2ggMjAxOSBWaXJ0dWFsIEludGVyaW0gU2VjZGlzcGF0Y2ggbWVl dGluZyBbMV0uICBPdXIgYXNzZXNzbWVudCBvZiB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGlzIGRp c2N1c3MgYW5kIGFzIHdlbGwgYXMgcHJvcG9zZWQgbmV4dCBzdGVwcyBhcmUgYmVsb3cuDQogICAg DQogICAgUmVnYXJkcywNCiAgICBSb21hbiBhbmQgQmVuDQogICAgDQogICAgWzFdIA0KICAgIGh0 dHBzOi8vbWFpbGFyY2hpdmUuLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoLzlBZnFyZWNa ZkZNbE1HeFNYT280RU5adHJWayA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy9zZWNkaXNwYXRjaC85QWZxcmVjWmZGTWxNR3hTWE9vNEVOWnRyVms+DQogICAgDQogICAgPT1b IFN1bW1hcnkgb2YgQURzIF09PQ0KICAgIEVESE9DIFN1bW1hcnkNCiAgICANCiAgICAtLS0tLVsg MS4gV2hhdCBpcyB0aGUgcHJvYmxlbSB3ZSBhcmUgZmFjZWQgd2l0aD8NCiAgICANCiAgICBUaGUg Y29tbXVuaXR5IG5lZWRzIGFuIEFLRSB0aGF0IGlzICdsaWdodHdlaWdodCcgKHBlciBzbGlkZSAj MyBvZiBbMl0pIGFuZCBlbmFibGVzIGZvcndhcmQgc2VjdXJpdHkgZm9yIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50cyB1c2luZyBPU0NPUkUgWzEzXS4gICdMaWdodHdlaWdodCcgcmVmZXJzIHRvOg0K ICAgIA0KICAgICoqIHJlc291cmNlIGNvbnN1bXB0aW9uLCBtZWFzdXJlZCBieSBieXRlcyBvbiB0 aGUgd2lyZSwgd2FsbC1jbG9jayB0aW1lIHRvIGNvbXBsZXRlIChpLmUuLCB0aGUgaW5pdGlhbCBs YXRlbmN5IGFkZGVkIHRvIGFwcGxpY2F0aW9uIHByb3RvY29scyBieSB0aGUgQUtFKSwgb3IgcG93 ZXIgKHBlciBzbGlkZSAjMTIgb2YgWzJdKQ0KICAgICoqIHRoZSBhbW91bnQgb2YgbmV3IGNvZGUg cmVxdWlyZWQgb24gZW5kIHN5c3RlbXMgd2hpY2ggYWxyZWFkeSBoYXZlIGFuIE9TQ09SRSBzdGFj ayBbNF0NCiAgICANCiAgICANCiAgICAtLS0tLVsgMi4gSXMgdGhlIHByb2JsZW0gdW5kZXJzdG9v ZCBhbmQgbmFycm93bHkgc2NvcGVkPw0KICAgIA0KICAgIFVzZSB3aXRoIE9TQ09SRSBpbXBsaWNp dGx5IGFzc3VtZXMgdGhhdCB0aGlzIEFLRSB3b3VsZCBzdXBwb3J0Og0KICAgICoqIHRyYW5zcG9y dCBvdmVyIENvQVAsIGFuZA0KICAgICoqIENPU0UgYWxnb3JpdGhtcw0KICAgIA0KICAgIFRoZSBz cGVjaWZpYyBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgdGhhdCB3ZSBhcmUgY29uc2lkZXJpbmcg dXNlIE5CLUlvVCwgNlRpU0NILCBhbmQgTG9SYVdBTi4gIFRoZSBkZXNpcmUgaXMgdG8gb3B0aW1p emUgdGhlIEFLRSB0byBiZSAnYXMgW3NtYWxsXSAuLi4gYXMgcmVhc29uYWJseSBhY2hpZXZhYmxl JyAocGVyIFszXSkgaW4gdGhlc2UgZW52aXJvbm1lbnRzLg0KICAgIA0KICAgICoqIFdpdGggcmVz cGVjdCB0byA2VGlTQ0gsIElFVEYgY29uc2Vuc3VzIG9uIHRoZSA2VGlTQ0ggV0cgY2hhcnRlciBo YXMgYWxyZWFkeSBpZGVudGlmaWVkIHRoZSBuZWVkIHRvICJzZWN1cltlXSB0aGUgam9pbiBwcm9j ZXNzIGFuZCBtYWtbZV0gdGhhdCBmaXQgd2l0aGluIHRoZSBjb25zdHJhaW50cyBvZiBoaWdoIGxh dGVuY3ksIGxvdyB0aHJvdWdocHV0IGFuZCBzbWFsbCBmcmFtZSBzaXplcyB0aGF0IGNoYXJhY3Rl cml6ZSBJRUVFODAyLjE1LjQNCiAgICAgVFNDSC4iIFsxMl0uDQogICAgKiogV2l0aCByZXNwZWN0 IHRvIE5CLUlvVCBhbmQgTG9SYVdBTiwgSUVURiBjb25zZW5zdXMgb24gdGhlIExQV0FOIFdHIGNo YXJ0ZXIgaGFzIGlkZW50aWZpZWQgdGhlIG5lZWQgdG8gaW1wcm92ZSB0aGUgdHJhbnNwb3J0IGNh cGFiaWxpdGllcyBvZiBMUFdBIG5ldHdvcmtzIHN1Y2ggYXMgTkItSW9UIGFuZCBMb1JhIHdob3Nl ICJjb21tb24gdHJhaXRzIGluY2x1ZGUgLi4uIGZyYW1lIHNpemVzIC4uLiBbb25dIHRoZSBvcmRl ciBvZiB0ZW5zIG9mIGJ5dGVzDQogICAgIHRyYW5zbWl0dGVkIGEgZmV3IHRpbWVzIHBlciBkYXkg YXQgdWx0cmEtbG93IHNwZWVkcyIgWzE2XS4gVGhpcyBpbmRpY2F0ZXMgSUVURiBpbnRlcmVzdCBp biBzdXBwb3J0aW5nIHRoZXNlIHJhZGlvIGVudmlyb25tZW50cywgdGhvdWdoIG5vIHNlY3VyaXR5 LXNwZWNpZmljIHJlcXVpcmVtZW50cyBhcmUgaW5jbHVkZWQgaW4gdGhlIGNoYXJ0ZXIuDQogICAg DQogICAgSXQgbWF5IGJlIG5lY2Vzc2FyeSB0byBldmFsdWF0ZSBvcHRpb25zIHRoYXQgbWFrZSBk aWZmZXJlbnQgdHJhZGUtb2ZmcyBhY3Jvc3MgYSBudW1iZXIgb2YgZGltZW5zaW9ucy4NCiAgICAN CiAgICAqKiBQZXIgJ2J5dGVzIG9uIHRoZSB3aXJlJywgaXQgaXMgZGVzaXJhYmxlIGZvciB0aGVz ZSBBS0UgbWVzc2FnZXMgdG8gZml0IGludG8gdGhlIE1UVSBzaXplIG9mIHRoZXNlIHByb3RvY29s czsgYW5kIGlmIG5vdCBwb3NzaWJsZSwgd2l0aGluIGFzIGZldyBmcmFtZXMgYXMgcG9zc2libGUu ICBOb3RlIHRoYXQgdXNpbmcgbXVsdGlwbGUgTVRVcyBjYW4gaGF2ZSBzaWduaWZpY2FudCBjb3N0 cyBpbiB0ZXJtcyBvZiB0aW1lIGFuZCBwb3dlciAobGlzdGVkDQogICAgIGJlbG93KS4gRm9yIDZU aVNDSCBzcGVjaWZpY2FsbHksIGFzIGEgdGltZS1zbGljZWQgbmV0d29yaywgdGhpcyBtZXRyaWMg KG9yIHJhdGhlciwgdGhlIHF1YW50aXphdGlvbiBpbnRvIGZyYW1lIGNvdW50KSBpcyBwYXJ0aWN1 bGFybHkgbm90ZXdvcnRoeSwgc2luY2UgbW9yZSBmcmFtZXMgY29udHJpYnV0ZSAgdG8gY29uZ2Vz dGlvbiBmb3Igc3BlY3RydW0gKGFuZCBjb25jb21pdGFudCBlcnJvciByYXRlcykgaW4gYSBub24t bGluZWFyIHdheSwgZXNwZWNpYWxseQ0KICAgICBpbiBzY2VuYXJpb3Mgd2hlbiBsYXJnZSBudW1i ZXJzIG9mIGluZGVwZW5kZW50IG5vZGVzIGFyZSBhdHRlbXB0aW5nIHRvIGV4ZWN1dGUgYW4gQUtF IHRvIGpvaW4gYSBuZXR3b3JrLg0KICAgIA0KICAgICoqIFBlciAndGltZScsIGl0IGlzIGRlc2ly YWJsZSBmb3IgdGhlIEFLRSBtZXNzYWdlIGV4Y2hhbmdlKHMpIHRvIGNvbXBsZXRlIGluIGEgcmVh c29uYWJsZSBhbW91bnQgb2YgdGltZSwgYm90aCBmb3IgYSBzaW5nbGUgdW5jb25nZXN0ZWQgZXhj aGFuZ2UgYW5kIHdoZW4gbXVsdGlwbGUgZXhjaGFuZ2VzIGFyZSBydW5uaW5nIGluIGFuIGludGVy bGVhdmVkIGZhc2hpb24uICBUaGlzIGxhdGVuY3kgbWF5IG5vdCBiZSBhIGxpbmVhciBmdW5jdGlv biBkZXBlbmRpbmcNCiAgICAgb24gY29uZ2VzdGlvbiBhbmQgdGhlIHNwZWNpZmljIHJhZGlvIHRl Y2hub2xvZ3kgdXNlZC4gIEZvciBMb1JhV0FOLCB3aGljaCBpcyBsZWdhbGx5IHJlcXVpcmVkIHRv IHVzZSBhIDElIChvciBzbWFsbGVyKSBkdXR5IGN5Y2xlLCBhIHBheWxvYWQgc3BsaXQgaW50byB0 d28gZnJhZ21lbnRzIGluc3RlYWQgb2Ygb25lIGluY3JlYXNlcyB0aGUgdGltZSB0byBjb21wbGV0 ZSB0aGUgc2VuZGluZyBvZiB0aGlzIHBheWxvYWQgYnkgMTAsMDAwJSAocGVyDQogICAgIHNsaWRl ICMxMCBvZiBbMl0pLiAgDQogICAgDQogICAgKiogUGVyICdwb3dlcicsIGl0IGlzIGRlc2lyYWJs ZSBmb3IgdGhlIHRyYW5zbWlzc2lvbiBvZiBBS0UgbWVzc2FnZXMgYW5kIGNyeXB0byB0byBkcmF3 IGFzIGxpdHRsZSBwb3dlciBhcyBwb3NzaWJsZSAgVGhlIGJlc3QgbWVjaGFuaXNtIGZvciBkb2lu ZyBzbyBkaWZmZXJzIGFjcm9zcyByYWRpbyB0ZWNobm9sb2dpZXMuICBGb3IgZXhhbXBsZSwgTkIt SW9UIHVzZXMgbGljZW5zZWQgc3BlY3RydW0gYW5kIHRodXMgY2FuIHRyYW5zbWl0IGF0IGhpZ2hl cg0KICAgICBwb3dlciB0byBpbXByb3ZlIGNvdmVyYWdlLCBtYWtpbmcgdGhlIHRyYW5zbWl0dGVk IGJ5dGUgY291bnQgcmVsYXRpdmVseSBtb3JlIGltcG9ydGFudCB0aGFuIGZvciBvdGhlciByYWRp byB0ZWNobm9sb2dpZXMuICBJbiBvdGhlciBjYXNlcywgdGhlIHJhZGlvIHRyYW5zbWl0dGVyIHdp bGwgYmUgYWN0aXZlIGZvciBhIGZ1bGwgTVRVIGZyYW1lIHJlZ2FyZGxlc3Mgb2YgaG93IG11Y2gg b2YgdGhlIGZyYW1lIGlzIG9jY3VwaWVkIGJ5IG1lc3NhZ2UNCiAgICAgY29udGVudCwgd2hpY2gg bWFrZXMgdGhlIGJ5dGUgY291bnQgbGVzcyBzZW5zaXRpdmUgZm9yIHRoZSBwb3dlciBjb25zdW1w dGlvbi4gIEluY3JlYXNlZCBwb3dlciBjb25zdW1wdGlvbiBpcyB1bmF2b2lkYWJsZSBpbiBwb29y IG5ldHdvcmsgY29uZGl0aW9ucywgc3VjaCBhcyBtb3N0IHdpZGUtYXJlYSBzZXR0aW5ncyBpbmNs dWRpbmcgTG9SYVdBTi4NCiAgICANCiAgICAqKiBQZXIgJ25ldyBjb2RlJywgaXQgaXMgZGVzaXJh YmxlIHRvIGludHJvZHVjZSBhcyBsaXR0bGUgbmV3IGNvZGUgYXMgcG9zc2libGUgb250byBPU0NP UkUtZW5hYmxlZCBkZXZpY2VzIHRvIHN1cHBvcnQgdGhpcyBuZXcgQUtFLiAgVGhlc2UgZGV2aWNl cyBoYXZlIG9uIHRoZSBvcmRlciBvZiAxMHMgb2Yga0Igb2YgbWVtb3J5IGFuZCAxMDBzIG9mIGtC IG9mIHN0b3JhZ2Ugb24gd2hpY2ggYW4gZW1iZWRkZWQgT1M7IGEgQ09BUCBzdGFjazsgQ09SRQ0K ICAgICBhbmQgQUtFIGxpYnJhcmllczsgYW5kIHRhcmdldCBhcHBsaWNhdGlvbnMgd291bGQgcnVu LiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGUgbWFqb3JpdHkgb2YgdGhpcyBzcGFjZSBpcyAgYXZh aWxhYmxlIGZvciBhY3R1YWwgYXBwbGljYXRpb24gbG9naWMsIGFzIG9wcG9zZWQgdG8gdGhlIHN1 cHBvcnQgbGlicmFyaWVzLg0KICAgIA0KICAgIEEga2V5IHF1ZXN0aW9uIHRvIGFuc3dlciBpcyB3 aGV0aGVyIGFueSBuZXcgc29sdXRpb24gd2lsbCByZWR1Y2UgdGhlc2UgcHJvcGVydGllcyB0byBh IHN1ZmZpY2llbnQgZXh0ZW50IHRvIG1lcml0IGludmVzdG1lbnQuDQogICAgDQogICAgLS0tLS1b IDMuIERvIHdlIGJlbGlldmUgaXQgaXMgcG9zc2libGUgdG8gZW5naW5lZXIgYSBzb2x1dGlvbj8N CiAgICANCiAgICBFREhPQyBbMV0gYXBwZWFycyB0byBiZSBhbiBleGlzdGVuY2UgcHJvb2YgdGhh dCBpdCBpcyBwb3NzaWJsZSB0byBwcm9kdWNlIGFuIEFLRSB0aGF0IG1lYW5pbmdmdWxseSByZWR1 Y2VzIHRoZSBjb3N0cyBhY3Jvc3MgYXQgbGVhc3QgdHdvIGRpbWVuc2lvbnMgaWRlbnRpZmllZCBp biBxdWVzdGlvbiAjMSBhbmQgMiAoYnl0ZXMgYW5kIHRpbWUpLiANCiAgICANCiAgICANCiAgICBF REhPQyBhcHBlYXJzIHRvIGZhdm9yYWJseSBvdXRwZXJmb3JtIFRMUy9Db0FQLCB0aGUgY3VycmVu dCB0ZWNobm9sb2d5LCByZWxhdGl2ZSB0byB0aGVzZSBkaW1lbnNpb25zLg0KICAgIA0KICAgIA0K ICAgICoqIFBlciAnYnl0ZXMgb24gdGhlIHdpcmUnLCBNVFUgc2l6ZXMgYW5kIHRoZWlyIGFsaWdu bWVudCB0byB0aGUgc2l6ZSBvZiBtZXNzYWdlcyBvZiBFREhPQyB2cy4gVExTL0NvQVAgY2FuIGJl IGZvdW5kIGluIHNsaWRlICMzMyBvZiBbMl0sIGFuZCBpbiBbNV0uICBBZGRpdGlvbmFsIGRldGFp bHMgZm9yIDZUaVNDSCBpbiBwYXJ0aWN1bGFyIGNhbiBiZSBmb3VuZCBpbiBzbGlkZSAzNi0zNyBv ZiBbMl0uDQogICAgDQogICAgKiogUGVyICd0aW1lJywgdGhlIGxhdGVuY3kgZHVlIHRvIGJhY2st b2ZmIHRpbWUgZXN0aW1hdGVzIHdpdGggRURIT0MgdnMuIFRMUy9Db0FQIHVzaW5nIExvUmFXQU4g Y2FuIGJlIGZvdW5kIGluIHNsaWRlICMzOSBvZiBbMl0NCiAgICANCiAgICAqKiBQZXIgJ3Bvd2Vy JywgZXN0aW1hdGVzIG9mIHRoZSBwb3dlciB1c2FnZSBvZiBFREhPQyB2cyBUTFMvQ29BUCB1c2lu ZyBOQi1Jb1QgY2FuIGJlIGZvdW5kIGluIHNsaWRlICMzNSBvZiBbMl0NCiAgICANCiAgICANCiAg ICAqKiBQZXIgJ25ldyBjb2RlJywgYmVpbmcgYWJsZSB0byByZXVzZSBwcmltaXRpdmVzIGZyb20g dGhlIGV4aXN0aW5nIENPU0Ugc3RhY2sgaXMgZXhwZWN0ZWQgdG8gYmVuZWZpdCB0aGUgY29kZSBz aXplIGZvciBFREhPQywgYnV0IG5vIGhhcmQgZGF0YSBpcyB5ZXQgYXZhaWxhYmxlIGZvciBjb21w YXJpc29uLiANCiAgICANCiAgICANCiAgICBFeHBsb3JhdG9yeSB3b3JrIHdpdGggY1RMUyBbMTBd IGFuZCBmZW10b1RMUyBbMTFdIGhhcyBzdWdnZXN0ZWQgdGhhdCBjZXJ0YWluIG9wdGltaXphdGlv bnMgdXNlZCBpbiBFREhPQyBjYW4gYWxzbyBiZSBhcHBsaWVkIHRvIGEgVExTL0NvQVAtdmFyaWFu dC4gIEhvdyB0aGlzIGltcGFjdHMgdGhlIG9yaWdpbmFsIGFzc3VtcHRpb25zIGFuZCBzZWN1cml0 eSBhbmFseXNpcyBmb3IgKEQpVExTIGlzIHVua25vd24uDQogICAgDQogICAgDQogICAgLS0tLS1b IDQuIElzIHRoaXMgcGFydGljdWxhciBwcm9wb3NhbCBhIGdvb2QgYmFzaXMgZm9yIHdvcmtpbmcg b24/IA0KICAgIA0KICAgIEVESE9DIHNob3dzIGdhaW5zIGluIGRlZmluaW5nIGFuIEFLRSB3aXRo IGZvcndhcmQgc2VjcmVjeSB0aGF0IGlzICdyZWFzb25hYmx5IHNtYWxsW2VyXScgdGhhbiB0aGUg YmFzZWxpbmUgb2YgKEQpVExTLiAgU3BlY2lmaWNhbGx5LCBpdCBhcHBlYXJzIHRoYXQgRURIT0Mg d291bGQgZW5hYmxlOg0KICAgICoqIGZvciA2VGlTQ0gsIGEgbW9yZSBlZmZpY2llbnQgbmV0d29y ayBqb2luIG9wZXJhdGlvbiwgd2l0aCBuZXR3b3JrIGpvaW4gdHJhZmZpYyBmaXR0aW5nIGluIG9u ZSBmcmFtZSBwZXIgZmxpZ2h0ICh0aGF0IGlzLCB0aGUgb3B0aW1hbCBwb3NzaWJsZSBiZWhhdmlv cikgaW4gdXAgdG8gYSA1LWhvcCBuZXR3b3JrIFsxN10NCiAgICAqKiBmb3IgTG9SYVdBTiwgYW4g QUtFIHdpdGggZm9yd2FyZCBzZWNyZWN5IHRoYXQgYXZvaWRzIHRoZSB1bmFjY2VwdGFibGUgYmFj a29mZi1pbmR1Y2VkIGxhdGVuY3kNCiAgICANCiAgICANCiAgICBBIGxpbWl0ZWQgaW50ZXJvcCB3 YXMgcGVyZm9ybWVkIG9uIGRyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlLTA1IChFREhPQykg YXQgSUVURiA5OCBiZXR3ZWVuIFsxNF0gYW5kIFsxNV0uICBEZXNwaXRlIHRoZSBpbmhlcmVudCBj aGFsbGVuZ2VzIG9mIHByb2R1Y2luZyBhIG5ldyBBS0UgdGhhdCBpcyBzZWN1cmUsIHRoZXJlIGlz IHJlYXNvbiB0byBoYXZlIGNvbmZpZGVuY2UgaW4gdGhlIHNlY3VyaXR5IGNsYWltcyBtYWRlIGJ5 IEVESE9DIC0tDQogICAgIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIC0wOCB3ZXJlIGZvcm1h bGx5IHZlcmlmaWVkIGJ5IFs4XVs5XS4gIElkZW50aWZpZWQgaXNzdWVzIGZyb20gdGhpcyBmb3Jt YWwgYW5hbHlzaXMgWzhdIHdlcmUgYWRkcmVzc2VkIGluIC0xMS4gIFRoZSBDRlJHIGNyeXB0byBy ZXZpZXcgcGFuZWwgY29uZHVjdGVkIHR3byByZXZpZXdzIFs2XVs3XS4gIFRoZXNlIHJldmlld3Mg Y29uZmlybWVkIHRoYXQgdGhlIHNlY3VyaXR5IGNsYWltcyBhcmUgcmVhc29uYWJsZSwNCiAgICAg YXR0ZXN0ZWQgdGhhdCB0aGUgaWRlbnRpZmllZCBpc3N1ZXMgZm91bmQgaW4gdGhlIGZvcm1hbCBh bmFseXNpcyBbOF0gd2VyZSBmaXhlZCwgYW5kIHByb3ZpZGVkIGFkZGl0aW9uYWwgcmVjb21tZW5k YXRpb25zLg0KICAgIA0KICAgIFJlLWVuY29kaW5nIG9mIHRoZSBUTFMgaGFuZHNoYWtlIGFzIHN1 Z2dlc3RlZCBieSBjVExTIFsxMF0gbWF5IGJlIHBvc3NpYmxlLiAgSG93ZXZlciwgYXMgb2YgeWV0 LCBjVExTIGlzIGFuIGluY29tcGxldGUgc3BlY2lmaWNhdGlvbiwgY1RMUyBoYXMgbm8gZm9ybWFs IHNlY3VyaXR5IGFuYWx5c2lzLCBhbmQgaXMgdGVjaG5pY2FsbHkgYSBuZXcgcHJvdG9jb2wuDQog ICAgDQogICAgLS0tLS1bIENvbmNsdXNpb24NCiAgICANCiAgICBUaGVyZSBhcHBlYXJzIHRvIGJl IGFuIHVuZGVyc3Rvb2QgYW5kIHNjb3BlZCBwcm9ibGVtIHRoYXQgaXMgZmVhc2libGUgdG8gZW5n aW5lZXIuICBBbW9uZyB0aGUgYXZhaWxhYmxlIHN0YXJ0aW5nIHBvaW50cyB0byBhZGRyZXNzIHRo ZSBwcm9ibGVtIGRlZmluZWQgaW4gcXVlc3Rpb24gIzEsIEVESE9DIHByZXNlbnRzIGEgdmlhYmxl IGNob2ljZS4gDQogICAgDQogICAgDQogICAgQ2hhcnRlcmluZyBhIG5hcnJvd2x5IHNjb3BlZCwg c2hvcnQtbGl2ZWQgV0cgaW4gdGhpcyBzcGFjZSB3aXRoIEVESE9DIGFzIGEgc3RhcnRpbmcgcG9p bnQgc2VlbXMgdG8gYmUgYW4gYXR0cmFjdGl2ZSBwYXRoIGZvcndhcmQsIGJ1dCB3ZSB3b3VsZCBs aWtlIHRvIHJlY2VpdmUgY29tbXVuaXR5IGZlZWRiYWNrIG9uIHRoZSBkZWdyZWUgb2Ygc3VwcG9y dCBmb3IgdGhpcyBhcHByb2FjaC4NCiAgICANCiAgICAtLS0tLVsgUmVmZXJlbmNlcw0KICAgIFsx XSANCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zZWxhbmRlci1hY2UtY29zZS1l Y2RoZS0xMy50eHQgPGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNlbGFuZGVyLWFjZS1j b3NlLWVjZGhlLTEzLnR4dD4NCiAgICBbMl0gDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOS1zZWNkaXNwYXRjaC0wMS9tYXRlcmlhbHMvc2xpZGVz LWludGVyaW0tMjAxOS1zZWNkaXNwYXRjaC0wMS1zZXNzYS1lZGhvYy4ucGRmIDxodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE5LXNlY2Rpc3BhdGNoLTAxL21h dGVyaWFscy9zbGlkZXMtaW50ZXJpbS0yMDE5LXNlY2Rpc3BhdGNoLTAxLXNlc3NhLWVkaG9jLnBk Zj4NCiAgICBbM10gDQogICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS4uaWV0Zi5vcmcvYXJjaC9tc2cv c2VjZGlzcGF0Y2gvLUdQcXN3blMtRFJ2ckFLc1BiZG9lczRZNGxFIDxodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoLy1HUHFzd25TLURSdnJBS3NQYmRvZXM0 WTRsRT4NCiAgICBbNF0gDQogICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS4uaWV0Zi5vcmcvYXJjaC9t c2cvc2VjZGlzcGF0Y2gvckpxdnN0TEhvN2FMZnUtT0RyaWwtd0lWbl8wIDxodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoL3JKcXZzdExIbzdhTGZ1LU9Ecmls LXdJVm5fMD4NCiAgICBbNV0gDQogICAgaHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQv ZC8xd0xvSWV4TUxHM1U5aVlPNWh6R3pLamt2aS1WRG5kUUJiWVJOc01VbGgtayA8aHR0cHM6Ly9k b2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xd0xvSWV4TUxHM1U5aVlPNWh6R3pLamt2aS1WRG5k UUJiWVJOc01VbGgtaz4NCiAgICBbNl0gDQogICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9jZnJnLzZXTjJDMlJZR1RJQUluRTJqSVVjbzZMOXBPOCA8aHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jZnJnLzZXTjJDMlJZR1RJQUluRTJqSVVjbzZMOXBP OD4NCiAgICBbN10gDQogICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9j ZnJnLzJPWTJvbTFGamhOTkJtVXp3WUpyb0h2N2VXUSA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9jZnJnLzJPWTJvbTFGamhOTkJtVXp3WUpyb0h2N2VXUT4NCiAgICBbOF0g DQogICAgaHR0cHM6Ly9hbGVzc2FuZHJvYnJ1bmkubmFtZS9wYXBlcnMvMTgtZWRob2MucGRmIDxo dHRwczovL2FsZXNzYW5kcm9icnVuaS5uYW1lL3BhcGVycy8xOC1lZGhvYy5wZGY+DQogICAgWzld IA0KICAgIGh0dHBzOi8vZ2l0aHViLmNvbS90aGVpc2dyb2VuYmVjaC9lZGhvYy1wcm92ZXJpZiA8 aHR0cHM6Ly9naXRodWIuY29tL3RoZWlzZ3JvZW5iZWNoL2VkaG9jLXByb3ZlcmlmPg0KICAgIFsx MF0gDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1j dGxzLTAxIDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtdGxzLWN0 bHMtMDE+DQogICAgWzExXSANCiAgICBodHRwczovL2dpdGh1Yi5jb20vYmlmdXJjYXRpb24vbWlu dC9jb21wYXJlL2Z0bHMgPGh0dHBzOi8vZ2l0aHViLmNvbS9iaWZ1cmNhdGlvbi9taW50L2NvbXBh cmUvZnRscz4NCiAgICBbMTJdIA0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2NoYXJ0ZXItaWV0Zi02dGlzY2gvIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9j aGFydGVyLWlldGYtNnRpc2NoLz4NCiAgICBbMTNdIA0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkvIDxodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5Lz4N CiAgICBbMTRdIA0KICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9hbGV4a3JvbnRpcmlzL0VESE9DLUMg PGh0dHBzOi8vZ2l0aHViLmNvbS9hbGV4a3JvbnRpcmlzL0VESE9DLUM+DQogICAgWzE1XSANCiAg ICBodHRwczovL2dpdGh1Yi5jb20vamltc2NoL0VESE9DLWNzaGFycCA8aHR0cHM6Ly9naXRodWIu Y29tL2ppbXNjaC9FREhPQy1jc2hhcnA+DQogICAgWzE2XSANCiAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtbHB3YW4vIDxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtbHB3YW4vPg0KICAgIFsxN10gDQogICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci4uaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNnRpc2NoLWR0c2VjdXJpdHkt emVyb3RvdWNoLWpvaW4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtNnRpc2NoLWR0c2VjdXJpdHktemVyb3RvdWNoLWpvaW4+DQogICAgDQogICAgPT1bIEVuZCBd PT0NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIFNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdA0KICAgIFNlY2Rpc3BhdGNoQGlldGYu b3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRj aA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 11 15:16:28 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AED1201E7 for ; Thu, 11 Apr 2019 15:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 Wu45OXD4jNWM for ; Thu, 11 Apr 2019 15:16:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4BD1201C0 for ; Thu, 11 Apr 2019 15:16:24 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x3BMGEK9022579 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 01:16:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x3BMGDkJ016427; Fri, 12 Apr 2019 01:16:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23727.48301.311217.991808@fireball.acr.fi> Date: Fri, 12 Apr 2019 01:16:13 +0300 From: Tero Kivinen To: John Mattsson Cc: Christopher Wood , "secdispatch\@ietf.org" In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 22:16:28 -0000 John Mattsson writes: > constrained some of them are. For the target network technologies > LPWAN over LoRaWAN and 6TiSCH over IEEE 802.15.4, the requirements > for message size are clear (under 50 bytes). IEEE 802.15.9 specifies how to use KMPs in IEEE 802.15.4, and it provides fragmentation of larger messages, so message size limits are not absolute in IEEE 802.15.4 environment. Of course the fewer fragments are needed the more efficient the protocol will be, but there is no absolute limit that is required. Some of the PHYs in IEEE 802.15.4 support larger frame sizes (up to 2048 bytes) and some of them support smaller (smallest are 20-30 bytes or so, but that PHY also includes another layer of fragmentation). The most common maximum frame size is 127 bytes, including header, and the header is usually less than 20 octets if no security header is used (which normally is not used for key management protocols as there is no keys yet). Even with security the overhead is usually about 12 bytes more, thus the total overhead is around 20-40 bytes. This means there is space for around 80-100 bytes of actual frame payload for IEEE 802.15.4 in normal cases. Targetting for 50 bytes is quite pessimistic for IEEE 802.15.4. -- kivinen@iki.fi From nobody Thu Apr 11 15:48:14 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C233112040B for ; Thu, 11 Apr 2019 15:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 wdlmftqSKWiO for ; Thu, 11 Apr 2019 15:48:09 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EF2120408 for ; Thu, 11 Apr 2019 15:48:09 -0700 (PDT) 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=h6aq4eeF/BBrpOYeboWGPAEIOgpu+R4BGKhgIXdd+KM=; b=hZCgySrfnh0VNCXvmEet19ep290IIdPHh1c2cxSpaD4KkxypfQyelhBZwQrK3JwQoDMRIjo/HrGjKs6M3a9031ufAB3orBJAxSpqo1bzPJYJlZTuz4DlI3hjRzx0g699DVr90aG45/xKhfRcW9Qbwjn/WZPxBigcyVos2sDP73o= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4329.eurprd07.prod.outlook.com (20.176.167.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.12; Thu, 11 Apr 2019 22:48:06 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Thu, 11 Apr 2019 22:48:06 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Richard Barnes , Roman Danyliw CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAALOb3sAABBDPIA= Date: Thu, 11 Apr 2019 22:48:06 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5dad31f-4083-4853-dbe5-08d6becfc37a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4329; x-ms-traffictypediagnostic: HE1PR07MB4329: x-ms-exchange-purlcount: 21 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(136003)(39860400002)(78114003)(199004)(189003)(53754006)(53936002)(256004)(14444005)(71200400001)(71190400001)(8936002)(83716004)(5660300002)(6246003)(66574012)(6436002)(53946003)(6512007)(6306002)(99286004)(30864003)(186003)(316002)(58126008)(53546011)(110136005)(8676002)(82746002)(26005)(97736004)(102836004)(229853002)(33656002)(76176011)(14454004)(410100003)(81166006)(81156014)(486006)(11346002)(446003)(2616005)(2906002)(476003)(561944003)(478600001)(85182001)(6506007)(86362001)(6486002)(7736002)(105586002)(305945005)(66066001)(36756003)(966005)(4326008)(6116002)(68736007)(25786009)(3846002)(106356001)(85202003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4329; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oQBQY7U+zWv7qqoE0+HGcx5k4R6DzzQQ+HElmc80mBiZZ1Xt/3q2CCBCpCYQJEJKzj+6EvG/2EjzphGQmugplpO3o9tUtbzoEYvpghIx1jQUINnmRXRTPJ2HvCnyc4WO1fZoaNZ++uNqKTjV8FOqL/Ra9WY1bWd8MBlXV+OP55POuWiKAbrQ44pe/KZ86YlACJWtBClpCoUPYKVCZk3hbblV8KFi8ggJwyelxYvVpnrfE5Ie21/Fwf312yQzdtlTTOObRzSKMau+mZDI+B+xdcXo6bLHLwm2mTsX4ws2vyIAeZw+GaTH8yw85EWq4fQp25mv3RJPTEIbt8cubFcJomIFN5BGnZ47x8SLsmmY4DwOKN9ULYUG9fVU9mSBhOuyLDL5Tmo3DmZ+qRm+aI/oiP0tQlOPXGFc9A5OnFHkexI= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5dad31f-4083-4853-dbe5-08d6becfc37a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 22:48:06.4809 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4329 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 22:48:13 -0000 SGkgUmljaGFyZCwNCg0KSSBsaWtlIHlvdXIgYW1iaXRpb24gdG8gb3B0aW1pemUgZnVydGhlci4g QnV0IGlmIHlvdSBjaGFuZ2UgVExTIGJ5IGNvcHlpbmcgb3ZlciBmZWF0dXJlcyBmcm9tIEVESE9D IHRoZW4gb2YgY291cnNlIG1lc3NhZ2Ugc2l6ZXMgd2lsbCBiZWNvbWUgb24gcGFyIHNpbmNlIHRo ZXkgYXJlIGJvdGggYmFzZWQgb24gU2lnbWEtSS4gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoYXQg aXMgbGVmdCBvZiBUTFMgYWZ0ZXIgDQoiVHdlYWtpbmcgVExTIGluIFF1ZXN0aW9uYWJsZSBXYXlz IiBhcyBpdCBpcyBuZWl0aGVyIGNvbXBhdGlibGUgd2l0aCBUTFMsIG5vciBkb2VzIHRoZSBzZWN1 cml0eSBwcm9vZnMgYXV0b21hdGljYWxseSBjYXJyeSBvdmVyLiANCg0KUGxlYXNlIGZpbmQgZnVy dGhlciBjb21tZW50cyBpbmxpbmUuDQoNCu+7v09uIDIwMTktMDQtMTEsIDE5OjAyLCAiU2VjZGlz cGF0Y2ggb24gYmVoYWxmIG9mIFJpY2hhcmQgQmFybmVzIiA8c2VjZGlzcGF0Y2gtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgcmxiQGlwdi5zeD4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQog ICAgDQogICAgU29ycnkgZm9yIHRoZSBsYXRlLWlzaCByZXBseS4gIEkgd2FudGVkIHRvIHdyaXRl IHNvbWUgY29kZSB0byBjb25maXJtIG15IHRob3VnaHRzIGhlcmUgYW5kIHByb3ZpZGUgc29tZSBj b25jcmV0ZSBkYXRhLg0KICAgIA0KICAgIHRsO2RyOiANCiAgICAqIEVESE9DIGlzIG5vdCBBTEFS UCwgYm90aCBpbiB0aGUg4oCcQUzigJ0gYW5kIOKAnFJQ4oCdIHNlbnNlcw0KICAgICogVExTLCB1 bm1vZGlmaWVkLCBjYW4gYmUgY29tcHJlc3NlZCB0byB3aXRoaW4gYSBmYWN0b3Igb2YgMiBvZiBF REhPQw0KICAgICogVExTIGNhbiBiZSB0d2Vha2VkIHRvIGJlIHNtYWxsZXIgdGhhbiBFREhPQyB3 aGlsZSBtYWtpbmcgZmV3ZXIgc2FjcmlmaWNlcyBjcnlwdG9ncmFwaGljYWxseQ0KICAgICogRm9y IHRoZSBSUEsgY2FzZSwgd2l0aCBUTFMgbnVtYmVycyBmcm9tIGltcGxlbWVudGF0aW9uLCBub3Qg c3BlY2lmaWNhdGlvbjoNCiAgICAgICAgKiBFREhPQyA9ICgzOSwgMTIwLCA4NSkNCiAgICAgICAg KiBUTFMgY29tcHJlc3NlZCA9ICg2NCwgMTgwLCAxMTYpDQogICAgICAgICogVExTIHdpdGggc2lt aWxhciBidXQgc21hbGxlciBzYWNyaWZpY2VzID0gKDMyLCAxMTMsIDgxKQ0KDQpbR1NdIFBsZWFz ZSB1c2UgdGhlIGN1cnJlbnQgdmVyc2lvbiAoLTEzKSBvZiBFREhPQyBpbiB5b3VyIGNvbXBhcmlz b24sIHRoZSBudW1iZXJzIGhlcmUgYXJlIG5vdCBjb3JyZWN0LiBQbGVhc2UgYWxzbyBtYWtlIHN1 cmUgdGhhdCB5b3UgY29tcGFyZSBwcm90b2NvbHMgd2hpY2ggaGF2ZSB0aGUgc2FtZSBmZWF0dXJl cy4gRm9yIGV4YW1wbGUgQ29ubmVjdGlvbiBpZGVudGlmaWVycyBhcmUgbWlzc2luZywgYW5kIGl0 IGlzIG5vdCBjbGVhciB0byBtZSBob3cgeW91IG5lZ290aWF0ZSBDT1NFIGFsZ29yaXRobXMgZm9y IEVESE9DIGFuZCBPU0NPUkUgaW4geW91ciBpbXBsZW1lbnRhdGlvbi4gVGhlcmVmb3JlIHRoZSBj b21wYXJpc29ucyBtYWRlIGluIHRoaXMgbWFpbCBhcmUgdm9pZC4NCiAgICANCiAgICBJdOKAmXMg d2VsbC1lc3RhYmxpc2hlZCBhdCB0aGlzIHBvaW50IHRoYXQgRURIT0MgbWFrZXMgc29tZSBjcnlw dG9ncmFwaGljIGNvbXByb21pc2VzIHZpcyDDoCB2aXMgVExTIHRoYXQgbm90IGV2ZXJ5b25lIGlz IGNvbWZvcnRhYmxlIHdpdGguIA0KDQpbR1NdIE5laXRoZXIgdGhlIGZvcm1hbCBhbmFseXNpcywg bm9yIHRoZSB0d28gQ0ZSRyBjcnlwdG8gcGFuZWwgcmV2aWV3cyBtYWRlIGFueSByZW1hcmtzIG9m IHRoYXQga2luZC4NCg0KIE5hbWVseSwgKDEpIGl0IG9taXRzIHRoZSByYW5kb20gdmFsdWVzIHNl bnQgaW4gdGhlIFRMUyBDbGllbnRIZWxsbyBhbmQgU2VydmVySGVsbG8gbWVzc2FnZXMsIGFuZCAo MikgaXQgcmVsaWVzIG9uIGFuIEFFQUQNCiAgICAgYXV0aGVudGljYXRpb24gdGFnIGluIHRoZSBy b2xlIHRoYXQgdGhlIEZpbmlzaGVkIE1BQyBwbGF5cyBpbiBUTFMuICBUaGUgdW5jZXJ0YWludHkg YXJvdW5kIHRoZXNlIG9wdGltaXphdGlvbnMgcmFpc2VzIHR3byBxdWVzdGlvbnM6DQogICAgDQog ICAgMS4gSG93IHNtYWxsIGNhbiBhIFRMUyBoYW5kc2hha2UgYmUgbWFkZSAqd2l0aG91dCogbWFr aW5nIHRoZXNlIGNvbXByb21pc2VzPw0KICAgIDIuIElmIHdlIG1ha2UgYW5hbG9nb3VzIGNvbXBy b21pc2VzIGluIFRMUywgd2hhdCBpcyB0aGUgbWluaW11bSBtZXNzYWdlIHNpemU/DQogICAgDQog ICAgVG8gYW5zd2VyIHRoZXNlIHF1ZXN0aW9ucyBlbXBpcmljYWxseSwgSSBtYWRlIGEgZm9yayBv ZiB0aGUgbWludCBUTFMgMS4zIGxpYnJhcnkgdGhhdCBpbXBsZW1lbnRzIHRoZXNlIG1vZGlmaWNh dGlvbnMgZm9yIHRoZSBSUEsgY2FzZS4gIFlvdSBjYW4gc2VlIHRoZSBkaWZmIGF0IHRoZSBmb2xs b3dpbmcgVVJMOyBpdCdzIGFib3V0IDgwMCBleHRyYSBMb0M6DQogICAgDQogICAgDQogICAgaHR0 cHM6Ly9naXRodWIuY29tL2JpZnVyY2F0aW9uL21pbnQvY29tcGFyZS9jdGxzDQogICAgDQogICAg DQogICAgKFRoZSBQU0sgY2FzZSB3b3VsZCBiZSBzdHJhaWdodGZvcndhcmQsIGp1c3QgZGlkbuKA mXQgaGF2ZSB0aW1lLikgDQogICAgDQogICAgDQogICAgIyBDb21wcmVzc2luZyBUTFMNCiAgICAN CiAgICBXZSBzdGFydCBmcm9tIHRoZSBvYnNlcnZhdGlvbiB0aGF0IHNpbXBseSByZS1lbmNvZGlu ZyBUTFMgbWVzc2FnZXMgZG9lc27igJl0IGNoYW5nZSB0aGUgc2VjdXJpdHkgcHJvb2ZzIGF0IGFs bC4gIElmIHRoZSBpbnB1dHMgdG8gdGhlIGNyeXB0b2dyYXBoaWMgZnVuY3Rpb25zIGFyZSB0aGUg c2FtZSwgdGhlbiB5b3UgZ2V0IHRoZSBzYW1lIGFzc3VyYW5jZXMgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIHlvdSBnZXQgdGhlbSBvZmYgdGhlIHdpcmUgb3IgcHJlbmVnb3RpYXRlDQogICAgIHRoZW0u ICBJZiB5b3UgYXNzdW1lLCBhcyBFREhPQyBkb2VzLCB0aGF0IHRoZSBuZWdvdGlhdGlvbiBiaXRz IG9mIFRMUyBjYW4gYmUgZG9uZSBvdXQgb2YgYmFuZA0KDQpbR1NdIE5vLCBjaXBoZXIgbmVnb3Rp YXRpb24gbXVzdCBiZSBpbmNsdWRlZCBhbmQgaXMgZG9uZSBpbiBFREhPQy4NCg0KLCB0aGVuIHlv dSBjYW4gbWFrZSBhIGNvbXByZXNzaW9uIGxheWVyIHRoYXQsIG9uIHNlbmRpbmcsIHJlbW92ZXMg YWxsIHRob3NlIHVubmVjZXNzYXJ5IGJpdHMsIGFuZCBvbiByZWNlaXZpbmcsIHJlY29uc3RydWN0 cyB0aGUgb3JpZ2luYWwgbWVzc2FnZSB1c2luZyB0aGUgcHJlbmVnb3RpYXRlZA0KICAgICB2YWx1 ZXMuLg0KICAgIA0KICAgIElmIHlvdSBkbyB0aGF0IHdpdGggdGhlIHN0YW5kYXJkIFRMUyBtdXR1 YWwtYXV0aCBoYW5kc2hha2UsIHRoZW4geW91IGFycml2ZSBhdCB0aGUgZm9sbG93aW5nIG1lc3Nh Z2Ugc2l6ZXMgYW5kIGFsbG9jYXRpb25zIG9mIGJ5dGVzOg0KICAgIA0KICAgIFRMUy1SUEstWklQ OiAoNjQsIDE4MCwgMTE2KQ0KICAgIE0xOiAzMiBbcmFuZF0gKyAzMiBbREhdDQogICAgTTI6IDMy IFtyYW5kXSArIDMyIFtESF0gKyA0IFtDZXJ0SURdICsgNjQgW1NJR10gKyAzMiBbTUFDXSArIDE2 IFtUQUddDQogICAgTTM6IDQgW0NlcnRJRF0gKyA2NCBbU0lHXSArIDMyIFtNQUNdICsgMTYgW1RB R10NCiAgICANCiAgICBUaGlzIHNlZW1zIGxpa2UgYSBwcmV0dHkgY29tcGVsbGluZyByZXN1bHQg aW4gaXRzZWxmLCBzaW5jZSB5b3UgZ2V0IHRoZSBmdWxsIHBvd2VyIG9mIFRMUyBoZXJlIGluIHRl cm1zIG9mIGFzc3VyYW5jZSDigJQgaW5jbHVkaW5nIHRoaW5ncyBsaWtlIGRvd25ncmFkZSBwcm90 ZWN0aW9uIG9uIGhvd2V2ZXIgeW91IGRpZCB0aGUgcHJlbmVnb3RpYXRpb24uICBBbmQgeW91IGdl dCBpdCBhbGwgd2l0aCBsZXNzIHRoYW4gMnggdGhlIG1lc3NhZ2Ugc2l6ZSBvZg0KICAgICBFREhP Qy4NCg0KW0dTXSBBcyB0aGlzIGRvZXMgbm90IGZpdCBpbnRvIHRoZSBvcHRpbWFsIG51bWJlciBv ZiBmcmFtZXMgZm9yIGUuZy4gTG9SYVdBTiBpdCBpcyBub3QgYSBjYW5kaWRhdGUgc29sdXRpb24u DQogICAgDQogICAgDQogICAgIyBUd2Vha2luZyBUTFMgaW4gUXVlc3Rpb25hYmxlIFdheXMNCiAg ICANCiAgICBOb3cgbGV04oCZcyBjb25zaWRlciB0aGUgRURIT0Mgc2hvcnRjdXRzIG5vdGVkIGFi b3ZlLiAgVGhlIHJlbW92YWwgb2YgdGhlIHJhbmRvbSB2YWx1ZXMgc2VlbXMgbW9yZSBwbGF1c2li bGUgdG8gbWUsIHNpbmNlIHRoZSBESCB2YWx1ZXMgY29udHJpYnV0ZSBmcmVzaCByYW5kb21uZXNz IGFueXdheS4gIFNvIHdlIGNhbiB0d2VhayB0aGUgVExTIHN0YWNrIHRvIHNldCB0aGUgcmFuZG9t cyB0byB6ZXJvLCBhbmQgd2Ugbm8gbG9uZ2VyIGhhdmUgdG8gc2VuZA0KICAgICB0aGVtIGluIG91 ciBtZXNzYWdlczoNCiAgICANCiAgICBUTFMtWklQLU5PUkFORDogKDMyLCAxNDgsIDExNikNCiAg ICBNMTogMzIgW0RIXQ0KICAgIE0yOiAzMiBbREhdICsgNCBbQ2VydElEXSArIDY0IFtTSUddICsg MzIgW01BQ10gKyAxNiBbVEFHXQ0KICAgIE0zOiA0IFtDZXJ0SURdICsgNjQgW1NJR10gKyAzMiBb TUFDXSArIDE2IFtUQUddDQogICAgDQogICAgQWxyZWFkeSwgd2XigJl2ZSBzdXJwYXNzZWQgRURI T0Mgb24gdGhlIGZpcnN0IG1lc3NhZ2UuICBSZW1vdmluZyB0aGUgRmluaXNoZWQgbWVzc2FnZSBp cyBkaWNpZXIsIHNpbmNlIGl0IGludHJvZHVjZXMgdGhlIGF1dGhlbnRpY2F0aW9uIGNvbmNlcm5z IHRoYXQgaGF2ZSBiZWVuIGRpc2N1c3NlZCBlbHNld2hlcmUuICBJbiBUTFMsIHdlIGNhbiDigJx2 aXJ0dWFsaXpl4oCdIHRoZSBGaW5pc2hlZCBtZXNzYWdlOyBzaW5jZSBlYWNoIHNpZGUgY2FuIGNv bXB1dGUNCiAgICAgdGhlIEZpbmlzaGVkIE1BQywgdGhleSBjYW4gaW5jbHVkZSBpdCBpbiB0aGUg a2V5IHNjaGVkdWxlIGV2ZW4gaWYgaXTigJlzIG5vdCBzZW50LiAgSWYgd2UgZG8gdGhhdCwgdGhl biB3ZSBlbmQgdXAgYmVsb3cgRURIT0PigJlzIG1lc3NhZ2Ugc2l6ZXM6DQogICAgDQogICAgVExT LVJQSy1aSVAtTk9SQU5ELVZGSU46ICgzMiwgMTEzLCA4MSkNCiAgICBNMTogMzIgW0RIXQ0KICAg IE0yOiAzMiBbREhdICsgMSBbQ2VydElEXSArIDY0IFtTSUddICsgMTYgW1RBR10NCiAgICBNMzog MSBbQ2VydElEXSArIDY0IFtTSUddICsgMTYgW1RBR10NCiAgICANCiAgICBUaGlzIGlzIGFuIGlu dGVyZXN0aW5nIHN0cnVjdHVyZSB0byBjb21wYXJlIHRvIEVESE9DLiAgRmlyc3QsIGl04oCZcyBu b3RhYmxlIHRoYXQgd2UgZ290IGhlcmUgd2l0aCBmZXdlciBzYWNyaWZpY2VzIHRoYW4gRURIT0Mu ICBXaGVyZSBFREhPQyB1c2VzIDgtYml0IHRhZ3MsIHdlIHVzZSBmdWxsLXNpemUuICBBbmQgdGhl IGZhY3QgdGhhdCBGaW5pc2hlZCBNQUNzIGVuZCB1cCBpbiB0aGUga2V5IHNjaGVkdWxlIG1lYW4g dGhhdCBhdCBsZWFzdCB0aGUNCiAgICAgYXBwbGljYXRpb24ga2V5cyB3aWxsIGRpdmVyZ2UgaWYg dGhlIHBhcnRpZXMgZGlzYWdyZWUuICAoVGhlIHRoaW5ncyBpbiBFREhPQyB0aGF0IHRoaXMgVExT IHZhcmlhbnQgbGFja3MsIGxpa2UgY29ubmVjdGlvbiBJRHMsIGNhbiBiZSBhZGRlZCBiYWNrIGF0 IHNpbWlsYXIgY29zdC4pICBTZWNvbmQsIHRoaXMgaGlnaGxpZ2h0cyBob3cgbWFueSBieXRlcyBF REhPQyB3YXN0ZXMgb24gZnJhbWluZzoNCiAgICANCiAgICBFREhPQy1SUEs6DQogICAgTTE6IDM5 ICA9IDMyIFtESF0gKyAxIFttc2dUeXBlXSArIDEgW0NJRF0gKyAyIFtjaXBoZXJzXSArIDMgW2Zy YW1pbmddDQogICAgTTI6IDEyMCA9IDMyIFtESF0gKyA0IFtLSURdICsgNjQgW1NJR10gKyA4IFtU QUddICsgMiBbQ0lEXSArIDEwIFtmcmFtaW5nXQ0KICAgIE0zOiA4NSAgPSA0IFtLSURdICsgNjQg W1NJR10gKyA4IFtUQUddICsgMSBbQ0lEXSArIDggW2ZyYW1pbmddDQoNCltHU13CoFRoZSAiZnJh bWluZyIgaGVyZSBpcyBwYXJ0bHkgQ0JPUiwgd2hpY2ggaXMgYSBmZWF0dXJlIGFuZCBub3QgYSBi dWcuDQogICAgDQogICAgSW4gc3VtbWFyeSwgaGF2aW5nIHRha2VuIGEgcHJldHR5IGRlZXAgZGl2 ZSBvbiB0aGlzIHByb2JsZW0sIGl04oCZcyBub3QgY2xlYXIgYXQgYWxsIHRvIG1lIHRoYXQgaWYg eW91IHdhbnQgYSBsaWdodHdlaWdodCBBS0UgKHJlZ2FyZGxlc3Mgb2YgdGhlIGRlZmluaXRpb24g b2Yg4oCcbGlnaHR3ZWlnaHTigJ0pIHRoYXQgRURIT0MgaXMgdGhlIGJlc3Qgc3RhcnRpbmcgcG9p bnQuICBXZSBjYW4gZ2V0IG1vc3Qgb2YgdGhlIHdheSB0aGVyZSBqdXN0IGJ5IHByb2ZpbGluZw0K ICAgICBkb3duIFRMUywgYW5kIGlmIHdlIG5lZWQgdG8gZ28gZmFydGhlciwgd2UgZ2V0IG1vcmUg c2F2aW5ncyB3aXRoIGhpZ2hlciBhc3N1cmFuY2UgYnkgdHdlYWtpbmcgVExTIHRoYW4gd2UgZG8g d2l0aCBhIGNsZWFuLXNsYXRlIGRlc2lnbiBsaWtlIEVESE9DLg0KDQpbR1NdIFRoZSBFREhPQyB5 b3UgY29tcGFyZSB3aXRoIGlzIGEgZm9ybWFsbHkgdmVyaWZpZWQgcHJvdG9jb2wsIHdoZXJlYXMg dGhpcyBpcyBhbiBlbWFpbCwgc28gaXQgcmVtYWlucyB0byBwcm92ZSB0aGUgcHJvcGVydGllcyB5 b3UgY2xhaW0uIE9uIGEgcG9zaXRpdmUgbm90ZSwgSSBzZWUgYSBjb252ZXJnZW5jZSBpbiB0aGUg cHJvdG9jb2wgeW91IHNrZXRjaCBhbmQgRURIT0MsIGJ1dCB0aGVyZSBhcmUgc3RpbGwgc29tZSBm ZWF0dXJlcyB5b3UgbmVlZCB0byBhZGQsIGxpa2UgQ0JPUiBhbmQgY2lwaGVyIHN1aXRlIG5lZ290 aWF0aW9uLg0KDQpHw7ZyYW4NCg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIE9u IFRodSwgTWFyIDI4LCAyMDE5IGF0IDY6MzMgQU0gUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3Jn PiB3cm90ZToNCiAgICANCiAgICANCiAgICBIaSENCiAgICANCiAgICBXZSBoYXZlIG9ic2VydmVk IHRoZSBjb250aW51ZWQgZGlzY3Vzc2lvbiBhbmQgaW50ZXJlc3QgaW4gdGhlIHRvcGljcyBkaXNj dXNzZWQgYXQgdGhlIE1hcmNoIDIwMTkgVmlydHVhbCBJbnRlcmltIFNlY2Rpc3BhdGNoIG1lZXRp bmcgWzFdLiAgT3VyIGFzc2Vzc21lbnQgb2YgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhpcyBkaXNj dXNzIGFuZCBhcyB3ZWxsIGFzIHByb3Bvc2VkIG5leHQgc3RlcHMgYXJlIGJlbG93Lg0KICAgIA0K ICAgIFJlZ2FyZHMsDQogICAgUm9tYW4gYW5kIEJlbg0KICAgIA0KICAgIFsxXSANCiAgICBodHRw czovL21haWxhcmNoaXZlLi5pZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC85QWZxcmVjWmZG TWxNR3hTWE9vNEVOWnRyVmsgPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv c2VjZGlzcGF0Y2gvOUFmcXJlY1pmRk1sTUd4U1hPbzRFTlp0clZrPg0KICAgIA0KICAgID09WyBT dW1tYXJ5IG9mIEFEcyBdPT0NCiAgICBFREhPQyBTdW1tYXJ5DQogICAgDQogICAgLS0tLS1bIDEu IFdoYXQgaXMgdGhlIHByb2JsZW0gd2UgYXJlIGZhY2VkIHdpdGg/DQogICAgDQogICAgVGhlIGNv bW11bml0eSBuZWVkcyBhbiBBS0UgdGhhdCBpcyAnbGlnaHR3ZWlnaHQnIChwZXIgc2xpZGUgIzMg b2YgWzJdKSBhbmQgZW5hYmxlcyBmb3J3YXJkIHNlY3VyaXR5IGZvciBjb25zdHJhaW5lZCBlbnZp cm9ubWVudHMgdXNpbmcgT1NDT1JFIFsxM10uICAnTGlnaHR3ZWlnaHQnIHJlZmVycyB0bzoNCiAg ICANCiAgICAqKiByZXNvdXJjZSBjb25zdW1wdGlvbiwgbWVhc3VyZWQgYnkgYnl0ZXMgb24gdGhl IHdpcmUsIHdhbGwtY2xvY2sgdGltZSB0byBjb21wbGV0ZSAoaS5lLiwgdGhlIGluaXRpYWwgbGF0 ZW5jeSBhZGRlZCB0byBhcHBsaWNhdGlvbiBwcm90b2NvbHMgYnkgdGhlIEFLRSksIG9yIHBvd2Vy IChwZXIgc2xpZGUgIzEyIG9mIFsyXSkNCiAgICAqKiB0aGUgYW1vdW50IG9mIG5ldyBjb2RlIHJl cXVpcmVkIG9uIGVuZCBzeXN0ZW1zIHdoaWNoIGFscmVhZHkgaGF2ZSBhbiBPU0NPUkUgc3RhY2sg WzRdDQogICAgDQogICAgDQogICAgLS0tLS1bIDIuIElzIHRoZSBwcm9ibGVtIHVuZGVyc3Rvb2Qg YW5kIG5hcnJvd2x5IHNjb3BlZD8NCiAgICANCiAgICBVc2Ugd2l0aCBPU0NPUkUgaW1wbGljaXRs eSBhc3N1bWVzIHRoYXQgdGhpcyBBS0Ugd291bGQgc3VwcG9ydDoNCiAgICAqKiB0cmFuc3BvcnQg b3ZlciBDb0FQLCBhbmQNCiAgICAqKiBDT1NFIGFsZ29yaXRobXMNCiAgICANCiAgICBUaGUgc3Bl Y2lmaWMgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzIHRoYXQgd2UgYXJlIGNvbnNpZGVyaW5nIHVz ZSBOQi1Jb1QsIDZUaVNDSCwgYW5kIExvUmFXQU4uICBUaGUgZGVzaXJlIGlzIHRvIG9wdGltaXpl IHRoZSBBS0UgdG8gYmUgJ2FzIFtzbWFsbF0gLi4uIGFzIHJlYXNvbmFibHkgYWNoaWV2YWJsZScg KHBlciBbM10pIGluIHRoZXNlIGVudmlyb25tZW50cy4NCiAgICANCiAgICAqKiBXaXRoIHJlc3Bl Y3QgdG8gNlRpU0NILCBJRVRGIGNvbnNlbnN1cyBvbiB0aGUgNlRpU0NIIFdHIGNoYXJ0ZXIgaGFz IGFscmVhZHkgaWRlbnRpZmllZCB0aGUgbmVlZCB0byAic2VjdXJbZV0gdGhlIGpvaW4gcHJvY2Vz cyBhbmQgbWFrW2VdIHRoYXQgZml0IHdpdGhpbiB0aGUgY29uc3RyYWludHMgb2YgaGlnaCBsYXRl bmN5LCBsb3cgdGhyb3VnaHB1dCBhbmQgc21hbGwgZnJhbWUgc2l6ZXMgdGhhdCBjaGFyYWN0ZXJp emUgSUVFRTgwMi4xNS40DQogICAgIFRTQ0guIiBbMTJdLg0KICAgICoqIFdpdGggcmVzcGVjdCB0 byBOQi1Jb1QgYW5kIExvUmFXQU4sIElFVEYgY29uc2Vuc3VzIG9uIHRoZSBMUFdBTiBXRyBjaGFy dGVyIGhhcyBpZGVudGlmaWVkIHRoZSBuZWVkIHRvIGltcHJvdmUgdGhlIHRyYW5zcG9ydCBjYXBh YmlsaXRpZXMgb2YgTFBXQSBuZXR3b3JrcyBzdWNoIGFzIE5CLUlvVCBhbmQgTG9SYSB3aG9zZSAi Y29tbW9uIHRyYWl0cyBpbmNsdWRlIC4uLiBmcmFtZSBzaXplcyAuLi4gW29uXSB0aGUgb3JkZXIg b2YgdGVucyBvZiBieXRlcw0KICAgICB0cmFuc21pdHRlZCBhIGZldyB0aW1lcyBwZXIgZGF5IGF0 IHVsdHJhLWxvdyBzcGVlZHMiIFsxNl0uIFRoaXMgaW5kaWNhdGVzIElFVEYgaW50ZXJlc3QgaW4g c3VwcG9ydGluZyB0aGVzZSByYWRpbyBlbnZpcm9ubWVudHMsIHRob3VnaCBubyBzZWN1cml0eS1z cGVjaWZpYyByZXF1aXJlbWVudHMgYXJlIGluY2x1ZGVkIGluIHRoZSBjaGFydGVyLg0KICAgIA0K ICAgIEl0IG1heSBiZSBuZWNlc3NhcnkgdG8gZXZhbHVhdGUgb3B0aW9ucyB0aGF0IG1ha2UgZGlm ZmVyZW50IHRyYWRlLW9mZnMgYWNyb3NzIGEgbnVtYmVyIG9mIGRpbWVuc2lvbnMuDQogICAgDQog ICAgKiogUGVyICdieXRlcyBvbiB0aGUgd2lyZScsIGl0IGlzIGRlc2lyYWJsZSBmb3IgdGhlc2Ug QUtFIG1lc3NhZ2VzIHRvIGZpdCBpbnRvIHRoZSBNVFUgc2l6ZSBvZiB0aGVzZSBwcm90b2NvbHM7 IGFuZCBpZiBub3QgcG9zc2libGUsIHdpdGhpbiBhcyBmZXcgZnJhbWVzIGFzIHBvc3NpYmxlLiAg Tm90ZSB0aGF0IHVzaW5nIG11bHRpcGxlIE1UVXMgY2FuIGhhdmUgc2lnbmlmaWNhbnQgY29zdHMg aW4gdGVybXMgb2YgdGltZSBhbmQgcG93ZXIgKGxpc3RlZA0KICAgICBiZWxvdykuIEZvciA2VGlT Q0ggc3BlY2lmaWNhbGx5LCBhcyBhIHRpbWUtc2xpY2VkIG5ldHdvcmssIHRoaXMgbWV0cmljIChv ciByYXRoZXIsIHRoZSBxdWFudGl6YXRpb24gaW50byBmcmFtZSBjb3VudCkgaXMgcGFydGljdWxh cmx5IG5vdGV3b3J0aHksIHNpbmNlIG1vcmUgZnJhbWVzIGNvbnRyaWJ1dGUgIHRvIGNvbmdlc3Rp b24gZm9yIHNwZWN0cnVtIChhbmQgY29uY29taXRhbnQgZXJyb3IgcmF0ZXMpIGluIGEgbm9uLWxp bmVhciB3YXksIGVzcGVjaWFsbHkNCiAgICAgaW4gc2NlbmFyaW9zIHdoZW4gbGFyZ2UgbnVtYmVy cyBvZiBpbmRlcGVuZGVudCBub2RlcyBhcmUgYXR0ZW1wdGluZyB0byBleGVjdXRlIGFuIEFLRSB0 byBqb2luIGEgbmV0d29yay4NCiAgICANCiAgICAqKiBQZXIgJ3RpbWUnLCBpdCBpcyBkZXNpcmFi bGUgZm9yIHRoZSBBS0UgbWVzc2FnZSBleGNoYW5nZShzKSB0byBjb21wbGV0ZSBpbiBhIHJlYXNv bmFibGUgYW1vdW50IG9mIHRpbWUsIGJvdGggZm9yIGEgc2luZ2xlIHVuY29uZ2VzdGVkIGV4Y2hh bmdlIGFuZCB3aGVuIG11bHRpcGxlIGV4Y2hhbmdlcyBhcmUgcnVubmluZyBpbiBhbiBpbnRlcmxl YXZlZCBmYXNoaW9uLiAgVGhpcyBsYXRlbmN5IG1heSBub3QgYmUgYSBsaW5lYXIgZnVuY3Rpb24g ZGVwZW5kaW5nDQogICAgIG9uIGNvbmdlc3Rpb24gYW5kIHRoZSBzcGVjaWZpYyByYWRpbyB0ZWNo bm9sb2d5IHVzZWQuICBGb3IgTG9SYVdBTiwgd2hpY2ggaXMgbGVnYWxseSByZXF1aXJlZCB0byB1 c2UgYSAxJSAob3Igc21hbGxlcikgZHV0eSBjeWNsZSwgYSBwYXlsb2FkIHNwbGl0IGludG8gdHdv IGZyYWdtZW50cyBpbnN0ZWFkIG9mIG9uZSBpbmNyZWFzZXMgdGhlIHRpbWUgdG8gY29tcGxldGUg dGhlIHNlbmRpbmcgb2YgdGhpcyBwYXlsb2FkIGJ5IDEwLDAwMCUgKHBlcg0KICAgICBzbGlkZSAj MTAgb2YgWzJdKS4gIA0KICAgIA0KICAgICoqIFBlciAncG93ZXInLCBpdCBpcyBkZXNpcmFibGUg Zm9yIHRoZSB0cmFuc21pc3Npb24gb2YgQUtFIG1lc3NhZ2VzIGFuZCBjcnlwdG8gdG8gZHJhdyBh cyBsaXR0bGUgcG93ZXIgYXMgcG9zc2libGUgIFRoZSBiZXN0IG1lY2hhbmlzbSBmb3IgZG9pbmcg c28gZGlmZmVycyBhY3Jvc3MgcmFkaW8gdGVjaG5vbG9naWVzLiAgRm9yIGV4YW1wbGUsIE5CLUlv VCB1c2VzIGxpY2Vuc2VkIHNwZWN0cnVtIGFuZCB0aHVzIGNhbiB0cmFuc21pdCBhdCBoaWdoZXIN CiAgICAgcG93ZXIgdG8gaW1wcm92ZSBjb3ZlcmFnZSwgbWFraW5nIHRoZSB0cmFuc21pdHRlZCBi eXRlIGNvdW50IHJlbGF0aXZlbHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBmb3Igb3RoZXIgcmFkaW8g dGVjaG5vbG9naWVzLiAgSW4gb3RoZXIgY2FzZXMsIHRoZSByYWRpbyB0cmFuc21pdHRlciB3aWxs IGJlIGFjdGl2ZSBmb3IgYSBmdWxsIE1UVSBmcmFtZSByZWdhcmRsZXNzIG9mIGhvdyBtdWNoIG9m IHRoZSBmcmFtZSBpcyBvY2N1cGllZCBieSBtZXNzYWdlDQogICAgIGNvbnRlbnQsIHdoaWNoIG1h a2VzIHRoZSBieXRlIGNvdW50IGxlc3Mgc2Vuc2l0aXZlIGZvciB0aGUgcG93ZXIgY29uc3VtcHRp b24uICBJbmNyZWFzZWQgcG93ZXIgY29uc3VtcHRpb24gaXMgdW5hdm9pZGFibGUgaW4gcG9vciBu ZXR3b3JrIGNvbmRpdGlvbnMsIHN1Y2ggYXMgbW9zdCB3aWRlLWFyZWEgc2V0dGluZ3MgaW5jbHVk aW5nIExvUmFXQU4uDQogICAgDQogICAgKiogUGVyICduZXcgY29kZScsIGl0IGlzIGRlc2lyYWJs ZSB0byBpbnRyb2R1Y2UgYXMgbGl0dGxlIG5ldyBjb2RlIGFzIHBvc3NpYmxlIG9udG8gT1NDT1JF LWVuYWJsZWQgZGV2aWNlcyB0byBzdXBwb3J0IHRoaXMgbmV3IEFLRS4gIFRoZXNlIGRldmljZXMg aGF2ZSBvbiB0aGUgb3JkZXIgb2YgMTBzIG9mIGtCIG9mIG1lbW9yeSBhbmQgMTAwcyBvZiBrQiBv ZiBzdG9yYWdlIG9uIHdoaWNoIGFuIGVtYmVkZGVkIE9TOyBhIENPQVAgc3RhY2s7IENPUkUNCiAg ICAgYW5kIEFLRSBsaWJyYXJpZXM7IGFuZCB0YXJnZXQgYXBwbGljYXRpb25zIHdvdWxkIHJ1bi4g IEl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIG1ham9yaXR5IG9mIHRoaXMgc3BhY2UgaXMgIGF2YWls YWJsZSBmb3IgYWN0dWFsIGFwcGxpY2F0aW9uIGxvZ2ljLCBhcyBvcHBvc2VkIHRvIHRoZSBzdXBw b3J0IGxpYnJhcmllcy4NCiAgICANCiAgICBBIGtleSBxdWVzdGlvbiB0byBhbnN3ZXIgaXMgd2hl dGhlciBhbnkgbmV3IHNvbHV0aW9uIHdpbGwgcmVkdWNlIHRoZXNlIHByb3BlcnRpZXMgdG8gYSBz dWZmaWNpZW50IGV4dGVudCB0byBtZXJpdCBpbnZlc3RtZW50Lg0KICAgIA0KICAgIC0tLS0tWyAz LiBEbyB3ZSBiZWxpZXZlIGl0IGlzIHBvc3NpYmxlIHRvIGVuZ2luZWVyIGEgc29sdXRpb24/DQog ICAgDQogICAgRURIT0MgWzFdIGFwcGVhcnMgdG8gYmUgYW4gZXhpc3RlbmNlIHByb29mIHRoYXQg aXQgaXMgcG9zc2libGUgdG8gcHJvZHVjZSBhbiBBS0UgdGhhdCBtZWFuaW5nZnVsbHkgcmVkdWNl cyB0aGUgY29zdHMgYWNyb3NzIGF0IGxlYXN0IHR3byBkaW1lbnNpb25zIGlkZW50aWZpZWQgaW4g cXVlc3Rpb24gIzEgYW5kIDIgKGJ5dGVzIGFuZCB0aW1lKS4gDQogICAgDQogICAgDQogICAgRURI T0MgYXBwZWFycyB0byBmYXZvcmFibHkgb3V0cGVyZm9ybSBUTFMvQ29BUCwgdGhlIGN1cnJlbnQg dGVjaG5vbG9neSwgcmVsYXRpdmUgdG8gdGhlc2UgZGltZW5zaW9ucy4NCiAgICANCiAgICANCiAg ICAqKiBQZXIgJ2J5dGVzIG9uIHRoZSB3aXJlJywgTVRVIHNpemVzIGFuZCB0aGVpciBhbGlnbm1l bnQgdG8gdGhlIHNpemUgb2YgbWVzc2FnZXMgb2YgRURIT0MgdnMuIFRMUy9Db0FQIGNhbiBiZSBm b3VuZCBpbiBzbGlkZSAjMzMgb2YgWzJdLCBhbmQgaW4gWzVdLiAgQWRkaXRpb25hbCBkZXRhaWxz IGZvciA2VGlTQ0ggaW4gcGFydGljdWxhciBjYW4gYmUgZm91bmQgaW4gc2xpZGUgMzYtMzcgb2Yg WzJdLg0KICAgIA0KICAgICoqIFBlciAndGltZScsIHRoZSBsYXRlbmN5IGR1ZSB0byBiYWNrLW9m ZiB0aW1lIGVzdGltYXRlcyB3aXRoIEVESE9DIHZzLiBUTFMvQ29BUCB1c2luZyBMb1JhV0FOIGNh biBiZSBmb3VuZCBpbiBzbGlkZSAjMzkgb2YgWzJdDQogICAgDQogICAgKiogUGVyICdwb3dlcics IGVzdGltYXRlcyBvZiB0aGUgcG93ZXIgdXNhZ2Ugb2YgRURIT0MgdnMgVExTL0NvQVAgdXNpbmcg TkItSW9UIGNhbiBiZSBmb3VuZCBpbiBzbGlkZSAjMzUgb2YgWzJdDQogICAgDQogICAgDQogICAg KiogUGVyICduZXcgY29kZScsIGJlaW5nIGFibGUgdG8gcmV1c2UgcHJpbWl0aXZlcyBmcm9tIHRo ZSBleGlzdGluZyBDT1NFIHN0YWNrIGlzIGV4cGVjdGVkIHRvIGJlbmVmaXQgdGhlIGNvZGUgc2l6 ZSBmb3IgRURIT0MsIGJ1dCBubyBoYXJkIGRhdGEgaXMgeWV0IGF2YWlsYWJsZSBmb3IgY29tcGFy aXNvbi4gDQogICAgDQogICAgDQogICAgRXhwbG9yYXRvcnkgd29yayB3aXRoIGNUTFMgWzEwXSBh bmQgZmVtdG9UTFMgWzExXSBoYXMgc3VnZ2VzdGVkIHRoYXQgY2VydGFpbiBvcHRpbWl6YXRpb25z IHVzZWQgaW4gRURIT0MgY2FuIGFsc28gYmUgYXBwbGllZCB0byBhIFRMUy9Db0FQLXZhcmlhbnQu ICBIb3cgdGhpcyBpbXBhY3RzIHRoZSBvcmlnaW5hbCBhc3N1bXB0aW9ucyBhbmQgc2VjdXJpdHkg YW5hbHlzaXMgZm9yIChEKVRMUyBpcyB1bmtub3duLg0KICAgIA0KICAgIA0KICAgIC0tLS0tWyA0 LiBJcyB0aGlzIHBhcnRpY3VsYXIgcHJvcG9zYWwgYSBnb29kIGJhc2lzIGZvciB3b3JraW5nIG9u PyANCiAgICANCiAgICBFREhPQyBzaG93cyBnYWlucyBpbiBkZWZpbmluZyBhbiBBS0Ugd2l0aCBm b3J3YXJkIHNlY3JlY3kgdGhhdCBpcyAncmVhc29uYWJseSBzbWFsbFtlcl0nIHRoYW4gdGhlIGJh c2VsaW5lIG9mIChEKVRMUy4gIFNwZWNpZmljYWxseSwgaXQgYXBwZWFycyB0aGF0IEVESE9DIHdv dWxkIGVuYWJsZToNCiAgICAqKiBmb3IgNlRpU0NILCBhIG1vcmUgZWZmaWNpZW50IG5ldHdvcmsg am9pbiBvcGVyYXRpb24sIHdpdGggbmV0d29yayBqb2luIHRyYWZmaWMgZml0dGluZyBpbiBvbmUg ZnJhbWUgcGVyIGZsaWdodCAodGhhdCBpcywgdGhlIG9wdGltYWwgcG9zc2libGUgYmVoYXZpb3Ip IGluIHVwIHRvIGEgNS1ob3AgbmV0d29yayBbMTddDQogICAgKiogZm9yIExvUmFXQU4sIGFuIEFL RSB3aXRoIGZvcndhcmQgc2VjcmVjeSB0aGF0IGF2b2lkcyB0aGUgdW5hY2NlcHRhYmxlIGJhY2tv ZmYtaW5kdWNlZCBsYXRlbmN5DQogICAgDQogICAgDQogICAgQSBsaW1pdGVkIGludGVyb3Agd2Fz IHBlcmZvcm1lZCBvbiBkcmFmdC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS0wNSAoRURIT0MpIGF0 IElFVEYgOTggYmV0d2VlbiBbMTRdIGFuZCBbMTVdLiAgRGVzcGl0ZSB0aGUgaW5oZXJlbnQgY2hh bGxlbmdlcyBvZiBwcm9kdWNpbmcgYSBuZXcgQUtFIHRoYXQgaXMgc2VjdXJlLCB0aGVyZSBpcyBy ZWFzb24gdG8gaGF2ZSBjb25maWRlbmNlIGluIHRoZSBzZWN1cml0eSBjbGFpbXMgbWFkZSBieSBF REhPQyAtLQ0KICAgICB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiAtMDggd2VyZSBmb3JtYWxs eSB2ZXJpZmllZCBieSBbOF1bOV0uICBJZGVudGlmaWVkIGlzc3VlcyBmcm9tIHRoaXMgZm9ybWFs IGFuYWx5c2lzIFs4XSB3ZXJlIGFkZHJlc3NlZCBpbiAtMTEuICBUaGUgQ0ZSRyBjcnlwdG8gcmV2 aWV3IHBhbmVsIGNvbmR1Y3RlZCB0d28gcmV2aWV3cyBbNl1bN10uICBUaGVzZSByZXZpZXdzIGNv bmZpcm1lZCB0aGF0IHRoZSBzZWN1cml0eSBjbGFpbXMgYXJlIHJlYXNvbmFibGUsDQogICAgIGF0 dGVzdGVkIHRoYXQgdGhlIGlkZW50aWZpZWQgaXNzdWVzIGZvdW5kIGluIHRoZSBmb3JtYWwgYW5h bHlzaXMgWzhdIHdlcmUgZml4ZWQsIGFuZCBwcm92aWRlZCBhZGRpdGlvbmFsIHJlY29tbWVuZGF0 aW9ucy4NCiAgICANCiAgICBSZS1lbmNvZGluZyBvZiB0aGUgVExTIGhhbmRzaGFrZSBhcyBzdWdn ZXN0ZWQgYnkgY1RMUyBbMTBdIG1heSBiZSBwb3NzaWJsZS4gIEhvd2V2ZXIsIGFzIG9mIHlldCwg Y1RMUyBpcyBhbiBpbmNvbXBsZXRlIHNwZWNpZmljYXRpb24sIGNUTFMgaGFzIG5vIGZvcm1hbCBz ZWN1cml0eSBhbmFseXNpcywgYW5kIGlzIHRlY2huaWNhbGx5IGEgbmV3IHByb3RvY29sLg0KICAg IA0KICAgIC0tLS0tWyBDb25jbHVzaW9uDQogICAgDQogICAgVGhlcmUgYXBwZWFycyB0byBiZSBh biB1bmRlcnN0b29kIGFuZCBzY29wZWQgcHJvYmxlbSB0aGF0IGlzIGZlYXNpYmxlIHRvIGVuZ2lu ZWVyLiAgQW1vbmcgdGhlIGF2YWlsYWJsZSBzdGFydGluZyBwb2ludHMgdG8gYWRkcmVzcyB0aGUg cHJvYmxlbSBkZWZpbmVkIGluIHF1ZXN0aW9uICMxLCBFREhPQyBwcmVzZW50cyBhIHZpYWJsZSBj aG9pY2UuIA0KICAgIA0KICAgIA0KICAgIENoYXJ0ZXJpbmcgYSBuYXJyb3dseSBzY29wZWQsIHNo b3J0LWxpdmVkIFdHIGluIHRoaXMgc3BhY2Ugd2l0aCBFREhPQyBhcyBhIHN0YXJ0aW5nIHBvaW50 IHNlZW1zIHRvIGJlIGFuIGF0dHJhY3RpdmUgcGF0aCBmb3J3YXJkLCBidXQgd2Ugd291bGQgbGlr ZSB0byByZWNlaXZlIGNvbW11bml0eSBmZWVkYmFjayBvbiB0aGUgZGVncmVlIG9mIHN1cHBvcnQg Zm9yIHRoaXMgYXBwcm9hY2guDQogICAgDQogICAgLS0tLS1bIFJlZmVyZW5jZXMNCiAgICBbMV0g DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNk aGUtMTMudHh0IDxodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zZWxhbmRlci1hY2UtY29z ZS1lY2RoZS0xMy50eHQ+DQogICAgWzJdIA0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbWVldGluZy9pbnRlcmltLTIwMTktc2VjZGlzcGF0Y2gtMDEvbWF0ZXJpYWxzL3NsaWRlcy1p bnRlcmltLTIwMTktc2VjZGlzcGF0Y2gtMDEtc2Vzc2EtZWRob2MuLnBkZiA8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOS1zZWNkaXNwYXRjaC0wMS9tYXRl cmlhbHMvc2xpZGVzLWludGVyaW0tMjAxOS1zZWNkaXNwYXRjaC0wMS1zZXNzYS1lZGhvYy5wZGY+ DQogICAgWzNdIA0KICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuLmlldGYub3JnL2FyY2gvbXNnL3Nl Y2Rpc3BhdGNoLy1HUHFzd25TLURSdnJBS3NQYmRvZXM0WTRsRSA8aHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC8tR1Bxc3duUy1EUnZyQUtzUGJkb2VzNFk0 bEU+DQogICAgWzRdIA0KICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuLmlldGYub3JnL2FyY2gvbXNn L3NlY2Rpc3BhdGNoL3JKcXZzdExIbzdhTGZ1LU9EcmlsLXdJVm5fMCA8aHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC9ySnF2c3RMSG83YUxmdS1PRHJpbC13 SVZuXzA+DQogICAgWzVdIA0KICAgIGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2Qv MXdMb0lleE1MRzNVOWlZTzVoekd6S2prdmktVkRuZFFCYllSTnNNVWxoLWsgPGh0dHBzOi8vZG9j cy5nb29nbGUuY29tL2RvY3VtZW50L2QvMXdMb0lleE1MRzNVOWlZTzVoekd6S2prdmktVkRuZFFC YllSTnNNVWxoLWs+DQogICAgWzZdIA0KICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvY2ZyZy82V04yQzJSWUdUSUFJbkUyaklVY282TDlwTzggPGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY2ZyZy82V04yQzJSWUdUSUFJbkUyaklVY282TDlwTzg+ DQogICAgWzddIA0KICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY2Zy Zy8yT1kyb20xRmpoTk5CbVV6d1lKcm9IdjdlV1EgPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvY2ZyZy8yT1kyb20xRmpoTk5CbVV6d1lKcm9IdjdlV1E+DQogICAgWzhdIA0K ICAgIGh0dHBzOi8vYWxlc3NhbmRyb2JydW5pLm5hbWUvcGFwZXJzLzE4LWVkaG9jLnBkZiA8aHR0 cHM6Ly9hbGVzc2FuZHJvYnJ1bmkubmFtZS9wYXBlcnMvMTgtZWRob2MucGRmPg0KICAgIFs5XSAN CiAgICBodHRwczovL2dpdGh1Yi5jb20vdGhlaXNncm9lbmJlY2gvZWRob2MtcHJvdmVyaWYgPGh0 dHBzOi8vZ2l0aHViLmNvbS90aGVpc2dyb2VuYmVjaC9lZGhvYy1wcm92ZXJpZj4NCiAgICBbMTBd IA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZXNjb3JsYS10bHMtY3Rs cy0wMSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxz LTAxPg0KICAgIFsxMV0gDQogICAgaHR0cHM6Ly9naXRodWIuY29tL2JpZnVyY2F0aW9uL21pbnQv Y29tcGFyZS9mdGxzIDxodHRwczovL2dpdGh1Yi5jb20vYmlmdXJjYXRpb24vbWludC9jb21wYXJl L2Z0bHM+DQogICAgWzEyXSANCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9j aGFydGVyLWlldGYtNnRpc2NoLyA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hh cnRlci1pZXRmLTZ0aXNjaC8+DQogICAgWzEzXSANCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5LyA8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eS8+DQog ICAgWzE0XSANCiAgICBodHRwczovL2dpdGh1Yi5jb20vYWxleGtyb250aXJpcy9FREhPQy1DIDxo dHRwczovL2dpdGh1Yi5jb20vYWxleGtyb250aXJpcy9FREhPQy1DPg0KICAgIFsxNV0gDQogICAg aHR0cHM6Ly9naXRodWIuY29tL2ppbXNjaC9FREhPQy1jc2hhcnAgPGh0dHBzOi8vZ2l0aHViLmNv bS9qaW1zY2gvRURIT0MtY3NoYXJwPg0KICAgIFsxNl0gDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWxwd2FuLyA8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWxwd2FuLz4NCiAgICBbMTddIA0KICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZ0aXNjaC1kdHNlY3VyaXR5LXpl cm90b3VjaC1qb2luIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LTZ0aXNjaC1kdHNlY3VyaXR5LXplcm90b3VjaC1qb2luPg0KICAgIA0KICAgID09WyBFbmQgXT09 DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBTZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCiAgICBTZWNkaXNwYXRjaEBpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2gN CiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Thu Apr 11 16:09:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE25120424 for ; Thu, 11 Apr 2019 16:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 TZlYQPwq-bEM for ; Thu, 11 Apr 2019 16:09:00 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40043.outbound.protection.outlook.com [40.107.4.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF5F1202D4 for ; Thu, 11 Apr 2019 16:09:00 -0700 (PDT) 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=/9cGhgY8/KYl6/W69oSJ2caPgfIBDO5B/T/MVh275o0=; b=BYppyGlDJ4tTYC4A/iunascqjIc1Wc35L2ia6wEX0hV/HeXJ77eGmEXHz2dArkmDWigItNKD72ftz/OedhRfIJWD3rm2q7uhsG/4ejQzuENJ5gbmqvdrnGqliI0LCC2C9NtXEGeKrTc/2LfMuhEM5nkcU49AdUWUJusQPp80ujQ= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3372.eurprd07.prod.outlook.com (10.170.247.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Thu, 11 Apr 2019 23:08:56 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Thu, 11 Apr 2019 23:08:56 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAJEpqUAAB7BU4AAGzlsAAAJZAKAAEp8a4AAAI7nAAAAMeuAAAwqWIA= Date: Thu, 11 Apr 2019 23:08:56 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> <3822.1555010100@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da632a58-5274-461d-9664-08d6bed2acad x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3372; x-ms-traffictypediagnostic: HE1PR07MB3372: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(376002)(366004)(396003)(189003)(199004)(486006)(106356001)(36756003)(478600001)(6486002)(85202003)(5660300002)(66066001)(305945005)(229853002)(81156014)(93886005)(14444005)(81166006)(71200400001)(6116002)(83716004)(7736002)(33656002)(3846002)(58126008)(97736004)(54906003)(316002)(110136005)(4326008)(186003)(76176011)(6506007)(53546011)(102836004)(256004)(71190400001)(99286004)(25786009)(6436002)(8936002)(53936002)(68736007)(26005)(66574012)(82746002)(8676002)(6512007)(85182001)(105586002)(2616005)(6246003)(86362001)(476003)(11346002)(14454004)(446003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3372; H:HE1PR07MB4172.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-message-info: XYkjNgRYLd2RuRmIsK1J4ubDZ5sNqWl4mkwkjhfN2jhY6bteIYFU0HEPOzL45vGynj1kQP6Xcs78HiNOVqPL0cJco6vTdbGt/PmZPkkqjdyXA+SFeLdfreGnz1Tdv7NIy+9S/pYisEsmM7/rNUk5/yAl9Dc2BDCRJPFlCYsamsfVtOlu3oDkAHug31dugZsK4ljkzHXffZ1fvoQfPOX2cplw8A0a+jCJgXYKjaYjbeaotbP9rWiEiMsbHPEdg63EF66ZiMSWejpZnxFnq+xr7I0NvVuuvn7SxlGxE+T38NBAGiaC0FOLyONan7MIV0LJe9bdYkmScd2Otqc4d68Hf19UZdFDLzWKKWJkj79PL/azR2ejqoWH66WHMLbj+WtIhzwbLxP+ND5SZhLXIeRAQ2IdafuGpMCYcCdhOg8xofk= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: da632a58-5274-461d-9664-08d6bed2acad X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 23:08:56.7119 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3372 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 23:09:03 -0000 SGkgUmljaGFyZCwNCg0K77u/T24gMjAxOS0wNC0xMSwgMjE6MjEsICJSaWNoYXJkIEJhcm5lcyIg PHJsYkBpcHYuc3g+IHdyb3RlOg0KDQogICAgT24gVGh1LCBBcHIgMTEsIDIwMTkgYXQgMzoxNSBQ TSBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYSA8bWFpbHRvOm1jciUy QmlldGZAc2FuZGVsbWFuLmNhPj4gd3JvdGU6DQogICAgDQogICAgDQogICAgUmljaGFyZCBCYXJu ZXMgPHJsYkBpcHYuc3g+IHdyb3RlOg0KICAgICAgICA+IEknZCBsaWtlIHRvIHB1c2ggYmFjayBv biB0aGlzIHBvaW50LiBJdCBtYXkgYmUgdGhhdCBFREhPQyBoYXMgYmVlbiBhcm91bmQgZm9yDQog ICAgICAgID4gYSB3aGlsZSBhbmQgYmVlbiB3ZWxsLXNvY2lhbGl6ZWQgd2l0aCB0aGUgSW9UIGNy b3dkLCBidXQgaXQgaXMgY2xlYXJseQ0KICAgICAgICA+IGRlZmljaWVudCBpbiBzZXZlcmFsIG90 aGVyIHR5cGVzIG9mIG1hdHVyaXR5LCBlLmcuLCByb2J1c3RuZXNzIG9mIGZvcm1hbA0KICAgICAg ICA+IGFuYWx5c2VzIGFuZCBzdGF0ZSBvZiBpbXBsZW1lbnRhdGlvbnMgKEFGQUlDVCkuDQogICAg DQogICAgSSB3YW50IHRvIGJlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgeW91Lg0KICAgIA0KICAg IElzIGl0IHlvdXIgb3BpbmlvbiB0aGEgdGhlIElFVEYgY2FuIG5vdCBmb3JtIGEgV0cgdW50aWwg YWZ0ZXIgYSBwcm90b2NvbCBoYXMNCiAgICBoYWQgZm9ybWFsIGFuYWx5c2lzPyAgSG93IG1hbnkg YW5hbHlzaXM/ICBIb3cgbWFueSB5ZWFycz8gIFdoaWNoIHB1YmxpY2F0aW9ucz8NCiAgICANCiAg ICANCiAgICBJIGRpZG4ndCBtZWFuIGFueXRoaW5nIHcuci50LiB0aGUgZm9ybWF0aW9uIG9mIGEg V0cuICBDYXJzdGVuJ3MgaW1wbGljYXRpb24gc2VlbWVkIHRvIGJlIHRoYXQgYW4gRURIT0MgV0cg Y291bGQgZGVsaXZlciBtb3JlIHF1aWNrbHkgdGhhbiwgZS5nLiwgb25lIHVzaW5nIFRMUyBhcyBh IHN0YXJ0aW5nIHBvaW50LiAgVGhhdCdzIHRoZSBwb2ludCBJIHdhcyBwdXNoaW5nIGJhY2sgb24g LS0gSSBob3BlIHdlIGFncmVlIHRoYXQgZGVsaXZlcmluZw0KICAgICBhIGZpbmFsIHNlY3VyaXR5 IHByb3RvY29sIHNob3VsZCBiZSBnYXRlZCBvbiByb2J1c3QgYW5hbHlzaXMgYW5kIG11bHRpcGxl IGltcGxlbWVudGF0aW9ucy4NCg0KW0dTXSBBcyBJIG1lbnRpb25lZCBpbiBteSByZWNlbnQgcmVw bHksIGdpdmVuIHRoZSBjaGFuZ2VzIHlvdSBtYWtlIHRvIFRMUyB0byBtYWtlIG1lc3NhZ2Ugc2l6 ZXMgb24gcGFyIHdpdGggRURIT0MsIGl0IGlzIGEgbmV3IHByb3RvY29sIHNvIHRoZSBzdGF0ZW1l bnQgYWJvdXQgcmVseWluZyBvbiB0aGUgYW5hbHlzaXMgb2YgVExTIGlzIHF1ZXN0aW9uYWJsZS4g Q29tcGFyaW5nIGltcGxlbWVudGF0aW9ucyB0aGVyZSBhcmUgY2xlYXJseSBtb3JlIG9mIFRMUywg YnV0LCBhZ2FpbiwgdGhpcyBpcyBhIG5ldyBwcm90b2NvbC4gDQoNCkfDtnJhbg0KDQoNCiAgICAN CiAgICAtLVJpY2hhcmQNCiAgICANCiAgICAgDQogICAgDQogICAgDQogICAgLS0NCiAgICBNaWNo YWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYSA8bWFpbHRvOm1jciUyQklFVEZA c2FuZGVsbWFuLmNhPj4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KICAgICAtPSBJUHY2IElv VCBjb25zdWx0aW5nID0tDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Apr 11 17:08:32 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09012004E for ; Thu, 11 Apr 2019 17:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 YIhkCrH2GcH3 for ; Thu, 11 Apr 2019 17:08:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0685C120013 for ; Thu, 11 Apr 2019 17:08:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x3C08NXU013047 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 03:08:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x3C08MsC016673; Fri, 12 Apr 2019 03:08:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23727.55030.643053.867113@fireball.acr.fi> Date: Fri, 12 Apr 2019 03:08:22 +0300 From: Tero Kivinen To: Cc: Richard Barnes , Michael Richardson , Carsten Bormann , "secdispatch\@ietf.org" , Martin Thomson In-Reply-To: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> <3822.1555010100@localhost> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 00:08:30 -0000 G=F6ran Selander writes: > [GS] As I mentioned in my recent reply, given the changes you make > to TLS to make message sizes on par with EDHOC, it is a new protocol > so the statement about relying on the analysis of TLS is > questionable. Comparing implementations there are clearly more of > TLS, but, again, this is a new protocol. I do not think it is new protocol, it could be done by just applying static header compression to TLS. Making static context header compression rules, that will omit for example most of the TLS framing which are not needed (as they are static) will allow take normal TLS frame, compress it to much smaller frame to be sent to other end. Then on the other end the static context header compression rules will decompress the frame and will get exactly same full TLS frame that was in the sender end. From the TLS library point of view the packets are full TLS 1.3 packets without any modifications. There might be some constrains what kind of TLS 1.3 frames the compression can do, for example there might be constraints that there cannot be any generic extensions, i.e., the TLS library would need to be configured so it will never even try to use them, the length of nonce might be fixed to specific length etc. --=20 kivinen@iki.fi From nobody Thu Apr 11 19:35:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2421203B9 for ; Thu, 11 Apr 2019 19:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3frm7S2sSbdz for ; Thu, 11 Apr 2019 19:34:59 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C44C120142 for ; Thu, 11 Apr 2019 19:34:59 -0700 (PDT) Received: from [192.168.217.106] (p54A6CE73.dip0.t-ipconnect.de [84.166.206.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44gMS04vJ9zypm; Fri, 12 Apr 2019 04:34:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <23727.55030.643053.867113@fireball.acr.fi> Date: Fri, 12 Apr 2019 04:34:55 +0200 Cc: =?utf-8?Q?G=C3=B6ran_Selander?= , Richard Barnes , Michael Richardson , "secdispatch@ietf.org" , Martin Thomson X-Mao-Original-Outgoing-Id: 576729293.491948-865a40aa37982bc899b17bd0cdcbc317 Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> <3822.1555010100@localhost> <23727.55030.643053.867113@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 02:35:02 -0000 On Apr 12, 2019, at 02:08, Tero Kivinen wrote: >=20 > it could be done by just [doing something contorted]. Sure, it could be (we have a lot of experience with header compression). (It is actually the only way to claim that we are =E2=80=9Cdoing TLS=E2=80= =9D, as opposed to a new thing that just happens to be TLS-branded as = well). But if that were the way forward, we would do compressed JSON over = compressed HTTP over compressed TCP over compressed IP. (Actually, we = *are* compressing IP, because a concise IP would be a nonstarter=E2=80=A6)= Some people are actually using heavy compression in their stacks (hey, = we just registered a deflated JSON Content-Format for CoAP!). But = generally: Concise wins over compressed. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Apr 12 04:57:27 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F711202A9 for ; Fri, 12 Apr 2019 04:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 aWToESdg43qJ for ; Fri, 12 Apr 2019 04:57:23 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50063.outbound.protection.outlook.com [40.107.5.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C46A1201AF for ; Fri, 12 Apr 2019 04:57:23 -0700 (PDT) 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=8ZULul0ziVzRmobcrxDKz7/CaBYO56ohBDu76gUee6Y=; b=bvo92yZdwfKsgA/5Jud2jf2K+PM/o/IWg5dnPULmgNk0FKzcP9bu+TUVCbk+cLGK1F2MeVhY8IL7FJkKk+FwRLgN2ucSTlmZhbNvjPiAr/Dmu6fXuGCPRoVWAkiyajEDYHOtI4ZdIxMupyJ/3duUwF+YrCbijSKgoQymFqix9i8= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3067.eurprd07.prod.outlook.com (10.170.244.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Fri, 12 Apr 2019 11:57:20 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Fri, 12 Apr 2019 11:57:20 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Tero Kivinen , John Mattsson CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AdTlTpiwSQddzTDHR8ys25qjhhiyAAJEpqUAAB7BU4AAGO0gAAAKvdwAAFJR+IAAIN4XgA== Date: Fri, 12 Apr 2019 11:57:20 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> <23727.48301.311217.991808@fireball.acr.fi> In-Reply-To: <23727.48301.311217.991808@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4dff74b5-3ca3-4439-8e87-08d6bf3e048d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3067; x-ms-traffictypediagnostic: HE1PR07MB3067: x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(199004)(189003)(229853002)(68736007)(85182001)(14444005)(305945005)(105586002)(8676002)(81156014)(82746002)(33656002)(6636002)(256004)(6506007)(85202003)(476003)(106356001)(102836004)(6486002)(71190400001)(81166006)(71200400001)(76176011)(5660300002)(6436002)(66066001)(14454004)(7736002)(8936002)(6246003)(11346002)(25786009)(486006)(26005)(446003)(316002)(97736004)(66574012)(186003)(99286004)(3846002)(83716004)(6116002)(4326008)(478600001)(2616005)(110136005)(6512007)(86362001)(53936002)(2906002)(58126008)(36756003)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3067; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3544U26JFgwfgxnW8LMGfJHB4/HYKKic7+lAgSyh9pQYI0mQQU83trPbG0vnZhvl5XN2dEt/8W6KXDRHDCx3KGhNLl887LdExGH2sQmY5kLwYwml1KtJufhCGrVvNyqlLaXoM+wtRHxWwljF5pqsKG1U7pxu581q3b91NSDeHMSi35WcEqfzkNL+jc+Hc1jwZ0DRPZGQZ+weZ/M2/IAYVm2cxcX6wGOWIX6qwf4zzYlSIZRhI/Bt4GfIc6pDGK8ByLDE2nEw3IHRKNmkJDnqaV5f30CioslhbsTOhlGh4I5elwbatNd+gNSCoPqsdF5xuPY95/zLPPnai+XZDzWIQ3UNg9alotEO3NP5oYz2KJu7wnpBCYccI5Kmd164rQhHCEt6czsLxUobzl2If7Nu5KGiexzE/CqnDiEAf2llwOE= Content-Type: text/plain; charset="utf-8" Content-ID: <14CC837522156443B8BB403345FAF03F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4dff74b5-3ca3-4439-8e87-08d6bf3e048d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 11:57:20.3596 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3067 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 11:57:26 -0000 SGkgVGVybywNCg0K77u/T24gMjAxOS0wNC0xMiwgMDA6MTYsICJUZXJvIEtpdmluZW4iIDxraXZp bmVuQGlraS5maT4gd3JvdGU6DQoNCiAgICBKb2huIE1hdHRzc29uIHdyaXRlczoNCiAgICA+IGNv bnN0cmFpbmVkIHNvbWUgb2YgdGhlbSBhcmUuIEZvciB0aGUgdGFyZ2V0IG5ldHdvcmsgdGVjaG5v bG9naWVzDQogICAgPiBMUFdBTiBvdmVyIExvUmFXQU4gYW5kIDZUaVNDSCBvdmVyIElFRUUgODAy LjE1LjQsIHRoZSByZXF1aXJlbWVudHMNCiAgICA+IGZvciBtZXNzYWdlIHNpemUgYXJlIGNsZWFy ICh1bmRlciA1MCBieXRlcykuDQogICAgDQogICAgSUVFRSA4MDIuMTUuOSBzcGVjaWZpZXMgaG93 IHRvIHVzZSBLTVBzIGluIElFRUUgODAyLjE1LjQsIGFuZCBpdA0KICAgIHByb3ZpZGVzIGZyYWdt ZW50YXRpb24gb2YgbGFyZ2VyIG1lc3NhZ2VzLCBzbyBtZXNzYWdlIHNpemUgbGltaXRzIGFyZQ0K ICAgIG5vdCBhYnNvbHV0ZSBpbiBJRUVFIDgwMi4xNS40IGVudmlyb25tZW50LiBPZiBjb3Vyc2Ug dGhlIGZld2VyDQogICAgZnJhZ21lbnRzIGFyZSBuZWVkZWQgdGhlIG1vcmUgZWZmaWNpZW50IHRo ZSBwcm90b2NvbCB3aWxsIGJlLCBidXQNCiAgICB0aGVyZSBpcyBubyBhYnNvbHV0ZSBsaW1pdCB0 aGF0IGlzIHJlcXVpcmVkLg0KICAgIA0KICAgIFNvbWUgb2YgdGhlIFBIWXMgaW4gSUVFRSA4MDIu MTUuNCBzdXBwb3J0IGxhcmdlciBmcmFtZSBzaXplcyAodXAgdG8NCiAgICAyMDQ4IGJ5dGVzKSBh bmQgc29tZSBvZiB0aGVtIHN1cHBvcnQgc21hbGxlciAoc21hbGxlc3QgYXJlIDIwLTMwIGJ5dGVz DQogICAgb3Igc28sIGJ1dCB0aGF0IFBIWSBhbHNvIGluY2x1ZGVzIGFub3RoZXIgbGF5ZXIgb2Yg ZnJhZ21lbnRhdGlvbikuDQogICAgDQogICAgVGhlIG1vc3QgY29tbW9uIG1heGltdW0gZnJhbWUg c2l6ZSBpcyAxMjcgYnl0ZXMsIGluY2x1ZGluZyBoZWFkZXIsIGFuZA0KICAgIHRoZSBoZWFkZXIg aXMgdXN1YWxseSBsZXNzIHRoYW4gMjAgb2N0ZXRzIGlmIG5vIHNlY3VyaXR5IGhlYWRlciBpcw0K ICAgIHVzZWQgKHdoaWNoIG5vcm1hbGx5IGlzIG5vdCB1c2VkIGZvciBrZXkgbWFuYWdlbWVudCBw cm90b2NvbHMgYXMgdGhlcmUNCiAgICBpcyBubyBrZXlzIHlldCkuIEV2ZW4gd2l0aCBzZWN1cml0 eSB0aGUgb3ZlcmhlYWQgaXMgdXN1YWxseSBhYm91dCAxMg0KICAgIGJ5dGVzIG1vcmUsIHRodXMg dGhlIHRvdGFsIG92ZXJoZWFkIGlzIGFyb3VuZCAyMC00MCBieXRlcy4gVGhpcyBtZWFucw0KICAg IHRoZXJlIGlzIHNwYWNlIGZvciBhcm91bmQgODAtMTAwIGJ5dGVzIG9mIGFjdHVhbCBmcmFtZSBw YXlsb2FkIGZvcg0KICAgIElFRUUgODAyLjE1LjQgaW4gbm9ybWFsIGNhc2VzLg0KICAgIA0KICAg IFRhcmdldHRpbmcgZm9yIDUwIGJ5dGVzIGlzIHF1aXRlIHBlc3NpbWlzdGljIGZvciBJRUVFIDgw Mi4xNS40Lg0KDQpbR1NdIFRoaXMgYmVuY2htYXJrIHByb3ZpZGVkIGJ5IDZUaVNDSCBpcyBsb29r aW5nIGF0IGJvb3RzdHJhcHBpbmcgaW4gYSBtdWx0aWhvcCBuZXR3b3JrIHVzaW5nIHRoZSA2dGlz Y2ggbWluaW1hbCBzZWN1cml0eSBzZXR1cCB3aXRoIGEgc3RhdGVsZXNzIGpvaW4gcHJveHksIHdo aWNoIGlzIGhvdyB0aGUgQUtFIGlzIHBsYW5uZWQgdG8gYmUgdXNlZCBpbiB0aGlzIGNvbnRleHQu IFRoZSBzdGF0ZWxlc3NuZXNzIG9mIHRoZSBwcm94eSBsZWFkcyB0byBhZGRpdGlvbmFsIG92ZXJo ZWFkIGluIHRoZSBuZXR3b3JrLg0KDQpHw7ZyYW4NCiANCg0K From nobody Fri Apr 12 09:20:35 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F07120136 for ; Fri, 12 Apr 2019 09:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 Va_UOqTfKG1F for ; Fri, 12 Apr 2019 09:20:31 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00072.outbound.protection.outlook.com [40.107.0.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409721200D7 for ; Fri, 12 Apr 2019 09:20:31 -0700 (PDT) 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=ScS8XEWgRQjee2bcXjSmcnTWwdQtfQF9XC3HKG0QwgA=; b=JaXFkwg+n0e4RMx134OSa78dspPcF1PgwuOBAQ2xx1ZR9smIuOWVPajDjAVPddbX6BC80qalhartX+Qxk66CL7/LwjdttDqVB4CcnM7YWE6mWOvrMnvjozlnu9h+kYiHNCMiPhQcuu5AwPmC4rfJ+gUiZG0dlhW09HotPHHUUX8= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3291.eurprd07.prod.outlook.com (10.170.246.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.8; Fri, 12 Apr 2019 16:20:28 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Fri, 12 Apr 2019 16:20:28 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "secdispatch@ietf.org" Thread-Topic: New Version Notification for draft-selander-lake-reqs-00.txt Thread-Index: AQHU8TrmwqejDFX+CUOuCcp26j3SF6Y41liA Date: Fri, 12 Apr 2019 16:20:28 +0000 Message-ID: References: <155507882604.16959.2935532240318784994.idtracker@ietfa.amsl.com> In-Reply-To: <155507882604.16959.2935532240318784994.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a02b5d1-f812-41ff-bfe5-08d6bf62c6f4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3291; x-ms-traffictypediagnostic: HE1PR07MB3291: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(376002)(39860400002)(396003)(189003)(199004)(85182001)(15650500001)(36756003)(8936002)(446003)(6512007)(11346002)(186003)(2351001)(6306002)(476003)(2473003)(2616005)(106356001)(105586002)(66066001)(2906002)(85202003)(316002)(25786009)(58126008)(81156014)(81166006)(6506007)(6916009)(1730700003)(8676002)(6436002)(5640700003)(2501003)(33656002)(229853002)(6486002)(102836004)(486006)(76176011)(97736004)(6116002)(3846002)(14444005)(305945005)(7736002)(68736007)(26005)(5660300002)(83716004)(82746002)(99286004)(71200400001)(53936002)(966005)(71190400001)(66574012)(86362001)(478600001)(14454004)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3291; H:HE1PR07MB4172.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-message-info: 8vgY555rx/u1+IJIKb3W4Ldd+Mal5R22DmDkMcmAIR9sYZTMLtnBFybhSg5lNV0hnkOHaUZaTB47DSccQ9Zonx5ntfRS7RnZNmGK0XlrU5XEwuwmMoLo9XPLwQ9tRThQjV5o8yb3swb5HZReNgDfp8kKK/50tM5socq001VxquT3HcOSnQjPykP7MsvfsZMxzwN3PfjgV9drPvalS18q93c/tT6dOV4FGURYS01WHRi3w+MhdpxN0Av+OeGUWiMEwYx9x3EgoFwcjSNDtunraZPhY6n1cO9c+dWifQCf+4f/K1OYgrtikqxeSuq2dZGnGO95250T3sgdp31JyXd3RY6BImFtcJkuAow3wnOCh6zuoXzBTOxrX+/CfnXwrfukKuJjA4HNiH+juerGLItVdvIJ0SW91BjIP3VQriLIzG8= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a02b5d1-f812-41ff-bfe5-08d6bf62c6f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 16:20:28.4092 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3291 Archived-At: Subject: [Secdispatch] FW: New Version Notification for draft-selander-lake-reqs-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:20:34 -0000 DQpPbiByZXF1ZXN0IEkgY29tcGlsZWQgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIGxpZ2h0d2Vp Z2h0IEFLRSBmb3IgT1NDT1JFIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBpbnRvIGEgZHJhZnQuIFRo aXMgaXMgbm90IGV4YWN0bHkgdGhlIGZvcm11bGF0aW9uIGJ5IHRoZSBzZWN1cml0eSBBRHMgYnV0 IHRoZSBtYWluIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgdGhlcmUuDQoNCkfDtnJhbg0KDQrvu79P biAyMDE5LTA0LTEyLCAxNjoyMCwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICANCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzLTAwLnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgR8O2cmFuIFNlbGFuZGVyIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAg SUVURiByZXBvc2l0b3J5Lg0KICAgIA0KICAgIE5hbWU6CQlkcmFmdC1zZWxhbmRlci1sYWtlLXJl cXMNCiAgICBSZXZpc2lvbjoJMDANCiAgICBUaXRsZToJCVJlcXVpcmVtZW50cyBmb3IgYSBMaWdo dHdlaWdodCBBS0UgZm9yIE9TQ09SRS4NCiAgICBEb2N1bWVudCBkYXRlOgkyMDE5LTA0LTEyDQog ICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdlczoJCTcNCiAgICBVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNl bGFuZGVyLWxha2UtcmVxcy0wMC50eHQNCiAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzLw0KICAgIEh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItbGFr ZS1yZXFzLTAwDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzDQogICAgDQogICAgDQogICAgQWJz dHJhY3Q6DQogICAgICAgVGhpcyBkb2N1bWVudCBjb250YWlucyB0aGUgcmVxdWlyZW1lbnRzIGZv ciBhIGxpZ2h0d2VpZ2h0DQogICAgICAgYXV0aGVudGljYXRlZCBrZXkgZXhjaGFuZ2UgcHJvdG9j b2wgZm9yIE9TQ09SRS4NCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAg DQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQog ICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICANCg0K From nobody Sat Apr 13 15:38:53 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817FD1200B3 for ; Sat, 13 Apr 2019 15:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 02LOZdz04FUq for ; Sat, 13 Apr 2019 15:38:49 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD52F1200CE for ; Sat, 13 Apr 2019 15:38:48 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Apr 2019 15:38:42 -0700 From: Jim Schaad To: 'Martin Thomson' , =?utf-8?Q?'G=C3=B6ran_Selander'?= , References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> In-Reply-To: <8e8873a9-2352-40af-8e60-370012393ccc@www.fastmail.com> Date: Sat, 13 Apr 2019 15:38:37 -0700 Message-ID: <000001d4f249$a4bea940$ee3bfbc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKfGLPmwj7uBgha/YkI9i6FfschWgGewDoPAkGqZwACwWencKRxUxdA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 22:38:51 -0000 > -----Original Message----- > From: Secdispatch On Behalf Of Martin > Thomson > Sent: Tuesday, April 9, 2019 7:57 PM > To: G=C3=B6ran Selander ; = secdispatch@ietf.org > Subject: Re: [Secdispatch] EDHOC Summary >=20 > On Tue, Apr 9, 2019, at 21:57, G=C3=B6ran Selander wrote: > > [GS] There seems to be consensus on the summary provided by the > > Security ADs, which includes the problem statement. >=20 > The entire point of my mail was to contest that point. >=20 > > [GS] There is no competing solution to the problem statement. As = been > > witnessed, people have waited for years for this to progress. > > Therefore I don't see anything premature with assuming EDHOC to be a > > starting point for the WG. >=20 > So you would prefer to disregard the work done by Eric and Jim = completely? Don't forget that one of the issues that was identified by me was that = by the time I was finished I felt that an entirely new security analysis = was going to be required to make sure that nothing was broken. Jim >=20 > > [GS] Concrete targets with numbers have been presented, for example > here: > > = https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjO > > pLjZGCU >=20 > Presented, yes. Agreed, no. >=20 > > [GS] A lightweight AKE on application layer, which this specific WG = is > > proposed to work on, is actually a missing enabler for constrained > > nodes to "communicate among themselves and with the wider = Internet". > > Indeed, if the security protocol is too heavy or needs to terminate = in > > a gateway due to change of transport etc., then end-to-end secure > > communication between the endpoints will not take place, thus > > preventing "to partake in permissionless innovation". >=20 > I think that you missed my point. If the goal is to provide an AKE, = then any > AKE will do. If the goal is to communicate with other Internet nodes, = then > you might argue that any AKE will do, but you at least have to = consider what > existing Internet nodes do in making that call. >=20 > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Sun Apr 14 05:35:02 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215A120098 for ; Sun, 14 Apr 2019 05:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=armh.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 dvMUCng4hRqb for ; Sun, 14 Apr 2019 05:34:56 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40067.outbound.protection.outlook.com [40.107.4.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BA1120041 for ; Sun, 14 Apr 2019 05:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uiSyKvZ2nM1h2aN4COapb0F8wjsxGwcZlc25SZPrmY0=; b=PojPIjtlAC+zWKsU3yGkgSV7p9h9yFsiszn4m5H0jhkGYSTTwSpVSscMSnVpFOTNXft6we1QgRF+dQS7jpGSLNkkQ7tgJ4UtHY/HqlJ/m/zbUqdg06V8l9usMxQiFCVuNy9UApSgY4xz8oWsT+7nkL0EamfWCBQcrSzW5l/2mRw= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3845.eurprd08.prod.outlook.com (20.178.89.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Sun, 14 Apr 2019 12:34:46 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.018; Sun, 14 Apr 2019 12:34:46 +0000 From: Hannes Tschofenig To: "secdispatch@ietf.org" Thread-Topic: Regarding the EDHOC IETF Developments Thread-Index: AdTytSpZeWWlsQi4T2mbc2Xc3fjEow== Date: Sun, 14 Apr 2019 12:34:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.119.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91afb7a3-9a01-4e33-741a-08d6c0d59430 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3845; x-ms-traffictypediagnostic: AM6PR08MB3845: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(376002)(366004)(396003)(346002)(40434004)(199004)(189003)(53754006)(97736004)(9686003)(33656002)(86362001)(966005)(2906002)(25786009)(54896002)(8676002)(6306002)(606006)(52536014)(74316002)(14454004)(68736007)(3846002)(7736002)(5660300002)(5024004)(81166006)(790700001)(6116002)(8936002)(256004)(2501003)(14444005)(71200400001)(71190400001)(1730700003)(81156014)(186003)(102836004)(6506007)(26005)(53936002)(6916009)(55016002)(6436002)(106356001)(478600001)(486006)(105586002)(476003)(72206003)(7696005)(2351001)(236005)(316002)(5640700003)(99286004)(66066001)(493534005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3845; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EaQQqGcozu7AEc8w/QutL5wqw1bv4ouhM9Lh0HOrw9PCp1cCfVFRNycFZXAb8Kfq5q25OWxySsAoP8wrHztVo3SPppa3z/VJMOGN2jglwVbWE+yRU+8UmHm2CLfJ8/Vmcj13g1xRwc2Tp8XRBInTEf7qzFYiNGkwDs+++QJE2R1DSaeu+JDDp8t4MjsEoBB2k59bna6K12+zalAHrfQRDmaOOebhdYidCvlMl45Eu1cLOKhpisMA6ECEUez6pXQulpxfMKkTDHipzs3Gyw7KsUe0PAgAd2DovifDxbfagki6ekL3G91EU3ncYqzkxHAvgDeS+S1VHsoNdV/QJht/2ZuqEr0GibF6L5543sIGW5p6zJgMYD8j9o+qcLZGiIicSWuadzluVOS9MhSUOkOqGK2bw9Nd2GMtXLJRNPuEutM= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3686C950A8C188748489409FFA2A0AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 91afb7a3-9a01-4e33-741a-08d6c0d59430 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2019 12:34:46.5753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3845 Archived-At: Subject: [Secdispatch] Regarding the EDHOC IETF Developments X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2019 12:35:00 -0000 --_000_AM6PR08MB3686C950A8C188748489409FFA2A0AM6PR08MB3686eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I was negatively surprised about the conclusions the area directors have ta= ken with regard to the proposed work on EDHOC. I have therefore used this as an opportunity to reach out to my co-workers = working on IoT deployments and our embedded implementations to collect thei= r feedback. They have not run into performance problems with the use of DTL= S & TLS 1.2 today (and our technology is used in lots of IoT environments).= Our Mbed teams are continuously working on enhancements, including RAM and= codesize improvements, for the security stacks and also for the IoT operat= ing systems. Things work fine today even though some of the newer IETF work= in the security area has not yet been utilized. Embedded system developmen= t takes time. The recent work on cTLS gives me the impression that performance optimizati= on can be gained incrementally. That's very good news for those companies w= ho have made several years of investment in those stacks. With our commitme= nt to build a high-quality embedded TLS/DTLS tack (along with the crypto) w= e are obviously interested to see further work in that direction. I have st= arted with a prototype implementation of the cTLS draft. It was a simple ex= ercise without many code changes. I understand that nobody wants to hear that they shouldn't standardize thei= r favourite solution. No IESG member likes to convey that message because t= hey would like to get re-elected. Working group chairs obviously don't like= to communicate such a message either. In the end, we have lots of solution= s in the hope that the "market will figure it out". Just look at how many s= olutions for communication security we have (see Section 4.2 of draft-irtf-= t2trg-iot-seccons-16) or how many different ways to provision credentials (= see draft-sarikaya-t2trg-sbootstrapping-06 and we are adding more -- https:= //bit.ly/2v4p7rn) there are. The IETF has become really efficient in publis= hing specs. That's great. It is a pity that the embedded community is not t= hat fast to deploy them. Normally, we do not care if someone proposes yet another solution. Unfortun= ately, for IoT-related stuff we spend a lot of time explaining why certain = solutions are neither available in IoT operating systems, why they are not = doing what they claim to do, or why the problems are actually somewhere els= e. We are worried about the collateral damage that results from standardizi= ng EDHOC. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB3686C950A8C188748489409FFA2A0AM6PR08MB3686eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I was negatively surprised about the conclusions the= area directors have taken with regard to the proposed work on EDHOC.

 

I have therefore used this as an opportunity to reac= h out to my co-workers working on IoT deployments and our embedded implemen= tations to collect their feedback. They have not run into performance probl= ems with the use of DTLS & TLS 1.2 today (and our technology is used in lots of IoT environments). Our Mbed t= eams are continuously working on enhancements, including RAM and codesize i= mprovements, for the security stacks and also for the IoT operating systems= . Things work fine today even though some of the newer IETF work in the security area has not yet been utilized= . Embedded system development takes time.

 

The recent work on cTLS gives me the impression that= performance optimization can be gained incrementally. That’s very go= od news for those companies who have made several years of investment in th= ose stacks. With our commitment to build a high-quality embedded TLS/DTLS tack (along with the crypto) we are obvio= usly interested to see further work in that direction. I have started with = a prototype implementation of the cTLS draft. It was a simple exercise with= out many code changes.

 

I understand that nobody wants to hear that they sho= uldn’t standardize their favourite solution. No IESG member likes to = convey that message because they would like to get re-elected. Working grou= p chairs obviously don’t like to communicate such a message either. In the end, we have lots of solutions in the hope t= hat the “market will figure it out”. Just look at how many solu= tions for communication security we have (see Section 4.2 of draft-irtf-t2t= rg-iot-seccons-16) or how many different ways to provision credentials (see draft-sarikaya-t2trg-sbootstrapping-06 and w= e are adding more -- https://bit.ly/2v4p7rn) there are. T= he IETF has become really efficient in publishing specs. That’s great= . It is a pity that the embedded community is not that fast to deploy them.=

 

Normally, we do not care if someone proposes yet ano= ther solution. Unfortunately, for IoT-related stuff we spend a lot of time = explaining why certain solutions are neither available in IoT operating sys= tems, why they are not doing what they claim to do, or why the problems are actually somewhere else. We are = worried about the collateral damage that results from standardizing EDHOC.

 

Ciao

Hannes

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB3686C950A8C188748489409FFA2A0AM6PR08MB3686eurp_-- From nobody Mon Apr 15 07:04:18 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6087120292 for ; Mon, 15 Apr 2019 07:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 QKISBhgwvo6n for ; Mon, 15 Apr 2019 07:04:10 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30044.outbound.protection.outlook.com [40.107.3.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C7B1203E2 for ; Mon, 15 Apr 2019 07:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ItZ/fozypB5imybzUKO3rBdMiEDEep3f/0T9yQjCoU=; b=NJQB+qZnArJKAoEAbcZc8mjI8/tiDA5F8YfRKGfdJU0bWy1uE01xWHE7u0wvL3PLCJHLlqF1wHMRASUSTvyaFLp9/dUw+MoincY2XxEWAHs099KwBrKsxIDgB44q16Wdi8/PW0VZjoXygUrh9AzPycnbIvUGqoZ70m5tgVG2IFQ= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3032.eurprd08.prod.outlook.com (52.135.163.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Mon, 15 Apr 2019 14:04:07 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 14:04:07 +0000 From: Hannes Tschofenig To: "secdispatch@ietf.org" Thread-Topic: IAB Workshop Call for Papers: Design Expectations vs. Deployment Reality Thread-Index: AdTyvoodAeOIKOERTpSWotUKgimzkA== Date: Mon, 15 Apr 2019 14:04:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a822070a-e45e-4c4a-a8b6-08d6c1ab39fb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB3032; x-ms-traffictypediagnostic: AM6PR08MB3032: x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39860400002)(396003)(346002)(136003)(40434004)(199004)(189003)(9686003)(99286004)(86362001)(33656002)(97736004)(25786009)(8676002)(54896002)(2906002)(6306002)(74316002)(14454004)(68736007)(3846002)(2473003)(52536014)(7736002)(5024004)(5660300002)(81166006)(790700001)(6116002)(8936002)(71190400001)(256004)(14444005)(1730700003)(2501003)(81156014)(71200400001)(229853002)(186003)(102836004)(6506007)(53936002)(55016002)(6916009)(53546011)(478600001)(106356001)(26005)(105586002)(6436002)(7696005)(72206003)(476003)(2351001)(66574012)(5640700003)(316002)(236005)(66066001)(486006)(225293001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3032; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 15GibvtaKDi/zQtYcQgvGvcxCOiCUIldMPS7KtrFeHghWnTLl437aEnWmz/YDREN5Tna1kx4fFljruCHTd8m9SQwV90W7lS7bcU0BTA9yddGQePflYt18FG/+R2lklzPMOeQdORL+1QENwdDmUb5n31VCtN0PI8p3i2UvoDf19K9J4RY5KtV/IadkO0F1nvChUmV+SfS0rm0WhG55jSGvL5ukA4c3Msxhz9CimPpei3lmFiVpwnFpen2fXcIqBgUjJymdeSLwexWrhD13AItiOiKLhNVqqDY3C5vs17bCAG4KySE2OZSpsjJ92Ef5LE+rprTuWma0LkMrIXoEpt97naNko7WDHMM53gjjjfGgtqnDn8VBMl205UOwCieg6rG14vMuyi4fuJRF6YGSAs5X+eJo0GgHJPyeVigoc6Wwkc= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3686A132DFD5A4F6C3E4FFAAFA2B0AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a822070a-e45e-4c4a-a8b6-08d6c1ab39fb X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 14:04:07.4705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3032 Archived-At: Subject: [Secdispatch] Fwd: IAB Workshop Call for Papers: Design Expectations vs. Deployment Reality X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 14:04:17 -0000 --_000_AM6PR08MB3686A132DFD5A4F6C3E4FFAAFA2B0AM6PR08MB3686eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVzogVGhpcyBtaWdodCBiZSBhIGdvb2Qgd29ya3Nob3AgZm9yIHRob3NlIHdvcmtpbmcgb24g SW9UIHNlY3VyaXR5DQoNCldpbGwgeW91IGhhdmUgdG8gcnVuIEVESE9DIG92ZXIgVExTIHRvIGdl dCBpdCBkZXBsb3llZCBpbiByZWFsIHdvcmxkIG5ldHdvcmtzPw0KDQpGcm9tOiBJQUIgQ2hhaXIg PGlhYi1jaGFpckBpYWIub3JnPG1haWx0bzppYWItY2hhaXJAaWFiLm9yZz4+DQpUbzogaWV0ZkBp ZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4sIGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFp bHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+LCBleGVjZEBpYWIub3JnPG1haWx0bzpleGVjZEBp YWIub3JnPg0KU3ViamVjdDogSUFCIFdvcmtzaG9wIENhbGwgZm9yIFBhcGVyczogRGVzaWduIEV4 cGVjdGF0aW9ucyB2cy4gRGVwbG95bWVudCBSZWFsaXR5DQpEYXRlOiBGcmksIDEyIEFwciAyMDE5 IDExOjI4OjQwIC0wNzAwDQpEZXNpZ24gRXhwZWN0YXRpb25zIHZzLiBEZXBsb3ltZW50IFJlYWxp dHkgaW4gUHJvdG9jb2wgRGV2ZWxvcG1lbnQNCkEgbnVtYmVyIG9mIHByb3RvY29scyBoYXZlIHBy ZXN1bWVkIHNwZWNpZmljIGRlcGxveW1lbnQgbW9kZWxzIGR1cmluZyB0aGUgZGV2ZWxvcG1lbnQg b3IgZWFybHkgZWxhYm9yYXRpb24gb2YgdGhlIHByb3RvY29sLiAgQWN0dWFsIGRlcGxveW1lbnRz IGhhdmUgc29tZXRpbWVzIHJ1biBjb250cmFyeSB0byB0aGVzZSBlYXJseSBleHBlY3RhdGlvbnMg d2hlbiBlY29ub21pZXMgb2Ygc2NhbGUsIEREb1MgcmVzaWxpZW5jZSwgbWFya2V0IGNvbnNvbGlk YXRpb24sIG9yIG90aGVyIGZhY3RvcnMgaGF2ZSBjb21lIGludG8gcGxheS4gVGhlc2UgZmFjdG9y cyBjYW4gcmVzdWx0IGluIHRoZSBkZXBsb3llZCByZWFsaXR5IGJlaW5nIGhpZ2hseSBjb25jZW50 cmF0ZWQuDQpUaGlzIGlzIGEgc2VyaW91cyBpc3N1ZSBmb3IgdGhlIEludGVybmV0LCBhcyBjb25j ZW50cmF0ZWQsIGNlbnRyYWxpemVkIGRlcGxveW1lbnQgbW9kZWxzIHByZXNlbnQgcmlza3MgdG8g dXNlciBjaG9pY2UsIHByaXZhY3ksIGFuZCBmdXR1cmUgcHJvdG9jb2wgZXZvbHV0aW9uLg0KT24g b2NjYXNpb24sIHRoZSBkaWZmZXJlbmNlcyB0byBleHBlY3RhdGlvbnMgd2VyZSBhbG1vc3QgaW1t ZWRpYXRlLCBidXQgdGhleSBhbHNvIG9jY3VyIGFmdGVyIGEgc2lnbmlmaWNhbnQgdGltZSBoYXMg cGFzc2VkIGZyb20gdGhlIHByb3RvY29s4oCZcyBpbml0aWFsIGRldmVsb3BtZW50Lg0KRXhhbXBs ZXMgaW5jbHVkZToNCkVtYWlsIHN0YW5kYXJkcywgd2hpY2ggcHJlc3VtZWQgbWFueSBwcm92aWRl cnMgcnVubmluZyBpbiBhIGxhcmdlbHkgdW5jb29yZGluYXRlZCBmYXNoaW9uLCBidXQgd2hpY2gg aGFzIHNlZW4gYm90aCBzaWduaWZpY2FudCBtYXJrZXQgY29uc29saWRhdGlvbiBhbmQgYSBuZWVk IGZvciBjb29yZGluYXRpb24gdG8gZGVmZW5kIGFnYWluc3Qgc3BhbSBhbmQgb3RoZXIgYXR0YWNr cy4gVGhlIGNvb3JkaW5hdGlvbiBhbmQgY2VudHJhbGl6ZWQgZGVmZW5zZSBtZWNoYW5pc21zIHNj YWxlIGJldHRlciBmb3IgbGFyZ2UgZW50aXRpZXMsIHdoaWNoIGhhcyBmdWVsZWQgYWRkaXRpb25h bCBjb25zb2xpZGF0aW9uLg0KVGhlIEROUywgd2hpY2ggcHJlc3VtZWQgZGVlcCBoaWVyYXJjaGll cyBidXQgaGFzIG9mdGVuIGJlZW4gZGVwbG95ZWQgaW4gbGFyZ2UsIGZsYXQgem9uZXMsIGxlYWRp bmcgdG8gdGhlIG5hbWVzZXJ2ZXJzIGZvciB0aG9zZSB6b25lcyBiZWNvbWluZyBjcml0aWNhbCBp bmZyYXN0cnVjdHVyZS4gRnV0dXJlIGRldmVsb3BtZW50cyBpbiBETlMgbWF5IHNlZSBjb25jZW50 cmF0aW9uIHRocm91Z2ggdGhlIHVzZSBvZiBnbG9iYWxseSBhdmFpbGFibGUgY29tbW9uIHJlc29s dmVyIHNlcnZpY2VzLCB3aGljaCBldm9sdmUgcmFwaWRseSBhbmQgY2FuIG9mZmVyIGJldHRlciBz ZWN1cml0eS4gUGFyYWRveGljYWxseSwgY29uY2VudHJhdGlvbiBvZiB0aGVzZSBxdWVyaWVzIGlu dG8gZmV3IHNlcnZpY2VzIGNyZWF0ZXMgbmV3IHNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbmNlcm5z Lg0KVGhlIFdlYiwgd2hpY2ggaXMgYnVpbHQgb24gYSBmdW5kYW1lbnRhbGx5IGRlY2VudHJhbGl6 ZWQgZGVzaWduLCBidXQgd2hpY2ggaXMgbm93IG9mdGVuIGRlbGl2ZXJlZCB3aXRoIHRoZSBhaWQg b2YgQ29udGVudCBEZWxpdmVyeSBOZXR3b3Jrcy4gIFRoZWlyIHNlcnZpY2VzIHByb3ZpZGUgc2Nh bGluZywgZGlzdHJpYnV0aW9uLCBhbmQgRGVuaWFsIG9mIFNlcnZpY2UgcHJldmVudGlvbiBpbiB3 YXlzIHRoYXQgbmV3IGVudHJhbnRzIGFuZCBzbWFsbGVyIHN5c3RlbXMgb3BlcmF0b3JzIHdvdWxk IGZpbmQgZGlmZmljdWx0IHRvIHJlcGxpY2F0ZS4gIFdoaWxlIHRydWx5IHNtYWxsIHNlcnZpY2Vz IGFuZCB0cnVseSBsYXJnZSBvbmVzIG1heSBvcGVyYXRlIHVzaW5nIG9ubHkgdGhlaXIgb3duIGlu ZnJhc3RydWN0dXJlLCBtYW55IG90aGVycyBhcmUgbGVmdCB3aXRoIHRoZSBvbmx5IHByYWN0aWNh bCBjaG9pY2UgYmVpbmcgdGhlIHVzZSBvZiBhIGdsb2JhbGx5IGF2YWlsYWJsZSBjb21tZXJjaWFs IHNlcnZpY2UuDQpTaW1pbGFyIGRldmVsb3BtZW50cyBtYXkgaGFwcGVuIHdpdGggZnV0dXJlIHRl Y2hub2xvZ2llcyBhbmQgc2VydmljZXMuIEZvciBpbnN0YW5jZSwgdGhlIGdyb3dpbmcgdXNlIG9m IE1hY2hpbmUgTGVhcm5pbmcgdGVjaG5vbG9neSBwcmVzZW50cyBjaGFsbGVuZ2VzIGZvciBkaXN0 cmlidXRpbmcgZWZmZWN0aXZlIGltcGxlbWVudGF0aW9uIG9mIGEgc2VydmljZSB0aHJvdWdob3V0 IGEgcG9vbCBvZiBtYW55IGRpZmZlcmVudCBwcm92aWRlcnMuDQpJbiBSRkMgNTIxOCB0aGUgSUFC IHRhY2tsZWQgd2hhdCBtYWRlIGZvciBhIHN1Y2Nlc3NmdWwgcHJvdG9jb2wuICBJbiBSRkMgODE3 MCwgdGhlIElBQiBkZXNjcmliZWQgaG93IHRvIGhhbmRsZSBwcm90b2NvbCB0cmFuc2l0aW9ucy4g IFRoaXMgd29ya3Nob3Agd2lsbCBleHBsb3JlIGNhc2VzIHdoZXJlIHRoZSBpbml0aWFsIHN5c3Rl bSBkZXNpZ24gYXNzdW1wdGlvbnMgdHVybmVkIG91dCB0byBiZSB3cm9uZywgbG9va2luZyBmb3Ig cGF0dGVybnMgaW4gd2hhdCBjYXVzZWQgdGhvc2UgYXNzdW1wdGlvbnMgdG8gZmFpbCAoZS5nLiwg Y29uY2VudHJhdGlvbiBkdWUgdG8gRERvUyByZXNpbGllbmNlKSBhbmQgaW4gaG93IHRob3NlIGZh aWx1cmVzIGltcGFjdCB0aGUgc2VjdXJpdHksIHByaXZhY3ksIGFuZCBtYW5hZ2VhYmlsaXR5IG9m IHRoZSByZXN1bHRpbmcgZGVwbG95bWVudHMuDQpXaGlsZSB0aGUgZXZlbnR1YWwgZ29hbHMgbWln aHQgaW5jbHVkZSBwcm9wb3NpbmcgY29tbW9uIHJlbWVkaWF0aW9ucyBmb3Igc3BlY2lmaWMgY2Fz ZXMgb2YgY29uZm91bmRlZCBwcm90b2NvbCBleHBlY3RhdGlvbnMsIHRoZSBJQUIgaXMgY3VycmVu dGx5IGludml0aW5nIHBhcGVycyB3aGljaDoNCiAg4oCiIERlc2NyaWJlIHNwZWNpZmljIGNhc2Vz IHdoZXJlIHN5c3RlbXMgYXNzdW1wdGlvbnMgZHVyaW5nIHByb3RvY29sIGRldmVsb3BtZW50IHdl cmUgY29uZm91bmRlZCBieSBsYXRlciBkZXBsb3ltZW50IGNvbmRpdGlvbnMuDQogIOKAoiBTdXJ2 ZXkgYSBzZXQgb2YgY2FzZXMgdG8gaWRlbnRpZnkgY29tbW9uIGZhY3RvcnMgaW4gdGhlc2UgY29u Zm91bmRlZCBleHBlY3RhdGlvbnMuDQogIOKAoiBFeHBsb3JlIHJlbWVkaWF0aW9ucyB3aGljaCBm b3N0ZXIgdXNlciBwcml2YWN5LCBzZWN1cml0eSBhbmQgcHJvdmlkZXIgZGl2ZXJzaXR5IGluIHRo ZSBmYWNlIG9mIHRoZXNlIGNoYW5nZXMuDQoNCkltcG9ydGFudCBEYXRlcw0KVGhlIHdvcmtzaG9w IHdpbGwgYmUgaGVsZCBKdW5lIDQtNSBpbiBIZWxzaW5raSwgRmlubGFuZC4NClBvc2l0aW9uIHBh cGVycyBtdXN0IGJlIHN1Ym1pdHRlZCBieSBNYXkgM3JkIGF0IHRoZSBsYXRlc3QuIFRoZSBwcm9n cmFtIGNvbW1pdHRlZSB3aWxsIHJldmlldyBzdWJtaXR0ZWQgcG9zaXRpb24gcGFwZXJzIGFuZCBz ZW5kIGFuIGludml0YXRpb24gdG8gdGhlIHdvcmtzaG9wIHRvIG9uZSBvZiB0aGUgcGFwZXIgYXV0 aG9ycy4gSW52aXRhdGlvbnMgd2lsbCBiZSBkaXN0cmlidXRlZCBieSBNYXkgOSBhdCB0aGUgbGF0 ZXN0Lg0KUG9zaXRpb24gUGFwZXIgUmVxdWlyZW1lbnRzDQpJbnRlcmVzdGVkIHBhcnRpZXMgbXVz dCBzdWJtaXQgYSBicmllZiBkb2N1bWVudCBvZiBvbmUgdG8gZm91ciBwYWdlcywgZm9ybWF0dGVk IGFzIEhUTUwsIFBERiwgb3IgcGxhaW4gdGV4dC4gV2Ugd2VsY29tZSBwYXBlcnMgdGhhdCBkZXNj cmliZSBleGlzdGluZyB3b3JrLCBhbnN3ZXJzIHRvIHRoZSBxdWVzdGlvbnMgbGlzdGVkIGFib3Zl LCBuZXcgcXVlc3Rpb25zLCB3cml0ZS11cHMgb2YgZGVwbG95bWVudCBleHBlcmllbmNlLCBsZXNz b25zLWxlYXJuZWQgZnJvbSBzdWNjZXNzZnVsIG9yIGZhaWxlZCBhdHRlbXB0cywgYW5kIGlkZWFs bHkgYSB2aXNpb24gdG93YXJkcyB0YWtpbmcgZGVwbG95bWVudCBjb25zaWRlcmF0aW9ucyBiZXR0 ZXIgaW4gYWNjb3VudCB3aGVuIGRlc2lnbmluZyBuZXcgSW50ZXJuZXQgdGVjaG5vbG9neS4gUmUt c3VibWlzc2lvbnMgZnJvbSB3b3JrIHByZXNlbnRlZCBlbHNld2hlcmUgYXJlIGFsbG93ZWQuDQpQ cm9ncmFtIENvbW1pdHRlZQ0KVGhlIGZvbGxvd2luZyBwZXJzb25zIGFyZSBJQUIgY29udGFjdHMg Zm9yIHRoaXMgd29ya3Nob3A6DQogICAgSmFyaSBBcmtrbw0KICAgIFN0ZXBoZW4gRmFycmVsbA0K ICAgIFRlZCBIYXJkaWUNCiAgICBDaHJpc3RpYW4gSHVpdGVtYQ0KICAgIE1lbGluZGEgU2hvcmUN CiAgICBCcmlhbiBUcmFtbWVsbA0KUG9zaXRpb24gcGFwZXJzIHNob3VsZCBiZSBzZW50IGJ5IGVt YWlsIHRvIGRlZHItcGNAaWFiLm9yZzxtYWlsdG86ZGVkci1wY0BpYWIub3JnPi4NCg0KbWptDQoN Cg0KDQoNCk1hcmllLUpvc2UgTW9udHBldGl0LCBQaC5ELg0KbWFyaWVqb0BtaXQuZWR1PG1haWx0 bzptYXJpZWpvQG1pdC5lZHU+DQptYXJpZUBtam1vbnRwZXRpdC5jb208bWFpbHRvOm1hcmllQG1q bW9udHBldGl0LmNvbT4NCisxLTc4MS01MjYtMjY2MQ0KQFNvY2lhbFRWTUlUDQoNCg0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM6PR08MB3686A132DFD5A4F6C3E4FFAAFA2B0AM6PR08MB3686eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNw YW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZXSVc6IFRoaXMgbWlnaHQgYmUgYSBnb29kIHdvcmtzaG9wIGZv ciB0aG9zZSB3b3JraW5nIG9uIElvVCBzZWN1cml0eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aWxsIHlvdSBoYXZlIHRvIHJ1biBFREhPQyBvdmVyIFRMUyB0byBnZXQgaXQgZGVwbG95ZWQgaW4g cmVhbCB3b3JsZCBuZXR3b3Jrcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMw LjBwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb206IElBQiBD aGFpciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhYi1jaGFpckBpYWIub3JnIj5pYWItY2hhaXJAaWFi Lm9yZzwvYT4mZ3Q7PGJyPg0KVG86Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmci PmlldGZAaWV0Zi5vcmc8L2E+LCZuYnNwOzxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGll dGYub3JnIj5pZXRmLWFubm91bmNlQGlldGYub3JnPC9hPiwmbmJzcDs8YSBocmVmPSJtYWlsdG86 ZXhlY2RAaWFiLm9yZyI+ZXhlY2RAaWFiLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBJQUIgV29ya3No b3AgQ2FsbCBmb3IgUGFwZXJzOiBEZXNpZ24gRXhwZWN0YXRpb25zIHZzLiBEZXBsb3ltZW50IFJl YWxpdHk8YnI+DQpEYXRlOiBGcmksIDEyIEFwciAyMDE5IDExOjI4OjQwIC0wNzAwPGJyPg0KRGVz aWduIEV4cGVjdGF0aW9ucyB2cy4gRGVwbG95bWVudCBSZWFsaXR5IGluIFByb3RvY29sIERldmVs b3BtZW50PGJyPg0KQSBudW1iZXIgb2YgcHJvdG9jb2xzIGhhdmUgcHJlc3VtZWQgc3BlY2lmaWMg ZGVwbG95bWVudCBtb2RlbHMgZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvciBlYXJseSBlbGFib3Jh dGlvbiBvZiB0aGUgcHJvdG9jb2wuICZuYnNwO0FjdHVhbCBkZXBsb3ltZW50cyBoYXZlIHNvbWV0 aW1lcyBydW4gY29udHJhcnkgdG8gdGhlc2UgZWFybHkgZXhwZWN0YXRpb25zIHdoZW4gZWNvbm9t aWVzIG9mIHNjYWxlLCBERG9TIHJlc2lsaWVuY2UsIG1hcmtldCBjb25zb2xpZGF0aW9uLA0KIG9y IG90aGVyIGZhY3RvcnMgaGF2ZSBjb21lIGludG8gcGxheS4gVGhlc2UgZmFjdG9ycyBjYW4gcmVz dWx0IGluIHRoZSBkZXBsb3llZCByZWFsaXR5IGJlaW5nIGhpZ2hseSBjb25jZW50cmF0ZWQuPGJy Pg0KVGhpcyBpcyBhIHNlcmlvdXMgaXNzdWUgZm9yIHRoZSBJbnRlcm5ldCwgYXMgY29uY2VudHJh dGVkLCBjZW50cmFsaXplZCBkZXBsb3ltZW50IG1vZGVscyBwcmVzZW50IHJpc2tzIHRvIHVzZXIg Y2hvaWNlLCBwcml2YWN5LCBhbmQgZnV0dXJlIHByb3RvY29sIGV2b2x1dGlvbi48YnI+DQpPbiBv Y2Nhc2lvbiwgdGhlIGRpZmZlcmVuY2VzIHRvIGV4cGVjdGF0aW9ucyB3ZXJlIGFsbW9zdCBpbW1l ZGlhdGUsIGJ1dCB0aGV5IGFsc28gb2NjdXIgYWZ0ZXIgYSBzaWduaWZpY2FudCB0aW1lIGhhcyBw YXNzZWQgZnJvbSB0aGUgcHJvdG9jb2zigJlzIGluaXRpYWwgZGV2ZWxvcG1lbnQuPGJyPg0KRXhh bXBsZXMgaW5jbHVkZTo8YnI+DQpFbWFpbCBzdGFuZGFyZHMsIHdoaWNoIHByZXN1bWVkIG1hbnkg cHJvdmlkZXJzIHJ1bm5pbmcgaW4gYSBsYXJnZWx5IHVuY29vcmRpbmF0ZWQgZmFzaGlvbiwgYnV0 IHdoaWNoIGhhcyBzZWVuIGJvdGggc2lnbmlmaWNhbnQgbWFya2V0IGNvbnNvbGlkYXRpb24gYW5k IGEgbmVlZCBmb3IgY29vcmRpbmF0aW9uIHRvIGRlZmVuZCBhZ2FpbnN0IHNwYW0gYW5kIG90aGVy IGF0dGFja3MuIFRoZSBjb29yZGluYXRpb24gYW5kIGNlbnRyYWxpemVkIGRlZmVuc2UNCiBtZWNo YW5pc21zIHNjYWxlIGJldHRlciBmb3IgbGFyZ2UgZW50aXRpZXMsIHdoaWNoIGhhcyBmdWVsZWQg YWRkaXRpb25hbCBjb25zb2xpZGF0aW9uLjxicj4NClRoZSBETlMsIHdoaWNoIHByZXN1bWVkIGRl ZXAgaGllcmFyY2hpZXMgYnV0IGhhcyBvZnRlbiBiZWVuIGRlcGxveWVkIGluIGxhcmdlLCBmbGF0 IHpvbmVzLCBsZWFkaW5nIHRvIHRoZSBuYW1lc2VydmVycyBmb3IgdGhvc2Ugem9uZXMgYmVjb21p bmcgY3JpdGljYWwgaW5mcmFzdHJ1Y3R1cmUuIEZ1dHVyZSBkZXZlbG9wbWVudHMgaW4gRE5TIG1h eSBzZWUgY29uY2VudHJhdGlvbiB0aHJvdWdoIHRoZSB1c2Ugb2YgZ2xvYmFsbHkgYXZhaWxhYmxl IGNvbW1vbg0KIHJlc29sdmVyIHNlcnZpY2VzLCB3aGljaCBldm9sdmUgcmFwaWRseSBhbmQgY2Fu IG9mZmVyIGJldHRlciBzZWN1cml0eS4gUGFyYWRveGljYWxseSwgY29uY2VudHJhdGlvbiBvZiB0 aGVzZSBxdWVyaWVzIGludG8gZmV3IHNlcnZpY2VzIGNyZWF0ZXMgbmV3IHNlY3VyaXR5IGFuZCBw cml2YWN5IGNvbmNlcm5zLjxicj4NClRoZSBXZWIsIHdoaWNoIGlzIGJ1aWx0IG9uIGEgZnVuZGFt ZW50YWxseSBkZWNlbnRyYWxpemVkIGRlc2lnbiwgYnV0IHdoaWNoIGlzIG5vdyBvZnRlbiBkZWxp dmVyZWQgd2l0aCB0aGUgYWlkIG9mIENvbnRlbnQgRGVsaXZlcnkgTmV0d29ya3MuICZuYnNwO1Ro ZWlyIHNlcnZpY2VzIHByb3ZpZGUgc2NhbGluZywgZGlzdHJpYnV0aW9uLCBhbmQgRGVuaWFsIG9m IFNlcnZpY2UgcHJldmVudGlvbiBpbiB3YXlzIHRoYXQgbmV3IGVudHJhbnRzIGFuZCBzbWFsbGVy DQogc3lzdGVtcyBvcGVyYXRvcnMgd291bGQgZmluZCBkaWZmaWN1bHQgdG8gcmVwbGljYXRlLiAm bmJzcDtXaGlsZSB0cnVseSBzbWFsbCBzZXJ2aWNlcyBhbmQgdHJ1bHkgbGFyZ2Ugb25lcyBtYXkg b3BlcmF0ZSB1c2luZyBvbmx5IHRoZWlyIG93biBpbmZyYXN0cnVjdHVyZSwgbWFueSBvdGhlcnMg YXJlIGxlZnQgd2l0aCB0aGUgb25seSBwcmFjdGljYWwgY2hvaWNlIGJlaW5nIHRoZSB1c2Ugb2Yg YSBnbG9iYWxseSBhdmFpbGFibGUgY29tbWVyY2lhbCBzZXJ2aWNlLjxicj4NClNpbWlsYXIgZGV2 ZWxvcG1lbnRzIG1heSBoYXBwZW4gd2l0aCBmdXR1cmUgdGVjaG5vbG9naWVzIGFuZCBzZXJ2aWNl cy4gRm9yIGluc3RhbmNlLCB0aGUgZ3Jvd2luZyB1c2Ugb2YgTWFjaGluZSBMZWFybmluZyB0ZWNo bm9sb2d5IHByZXNlbnRzIGNoYWxsZW5nZXMgZm9yIGRpc3RyaWJ1dGluZyBlZmZlY3RpdmUgaW1w bGVtZW50YXRpb24gb2YgYSBzZXJ2aWNlIHRocm91Z2hvdXQgYSBwb29sIG9mIG1hbnkgZGlmZmVy ZW50IHByb3ZpZGVycy4mbmJzcDs8YnI+DQpJbiZuYnNwO1JGQyA1MjE4Jm5ic3A7dGhlIElBQiB0 YWNrbGVkIHdoYXQgbWFkZSBmb3IgYSBzdWNjZXNzZnVsIHByb3RvY29sLiAmbmJzcDtJbiZuYnNw O1JGQyA4MTcwLCB0aGUgSUFCIGRlc2NyaWJlZCBob3cgdG8gaGFuZGxlIHByb3RvY29sIHRyYW5z aXRpb25zLiAmbmJzcDtUaGlzIHdvcmtzaG9wIHdpbGwgZXhwbG9yZSBjYXNlcyB3aGVyZSB0aGUg aW5pdGlhbCBzeXN0ZW0gZGVzaWduIGFzc3VtcHRpb25zIHR1cm5lZCBvdXQgdG8gYmUgd3Jvbmcs IGxvb2tpbmcgZm9yIHBhdHRlcm5zIGluDQogd2hhdCBjYXVzZWQgdGhvc2UgYXNzdW1wdGlvbnMg dG8gZmFpbCAoZS5nLiwgY29uY2VudHJhdGlvbiBkdWUgdG8gRERvUyByZXNpbGllbmNlKSBhbmQg aW4gaG93IHRob3NlIGZhaWx1cmVzIGltcGFjdCB0aGUgc2VjdXJpdHksIHByaXZhY3ksIGFuZCBt YW5hZ2VhYmlsaXR5IG9mIHRoZSByZXN1bHRpbmcgZGVwbG95bWVudHMuPGJyPg0KV2hpbGUgdGhl IGV2ZW50dWFsIGdvYWxzIG1pZ2h0IGluY2x1ZGUgcHJvcG9zaW5nIGNvbW1vbiByZW1lZGlhdGlv bnMgZm9yIHNwZWNpZmljIGNhc2VzIG9mIGNvbmZvdW5kZWQgcHJvdG9jb2wgZXhwZWN0YXRpb25z LCB0aGUgSUFCIGlzIGN1cnJlbnRseSBpbnZpdGluZyBwYXBlcnMgd2hpY2g6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsgPC9zcGFuPuKAoiBEZXNjcmliZSBzcGVjaWZpYyBjYXNlcyB3aGVyZSBzeXN0 ZW1zIGFzc3VtcHRpb25zIGR1cmluZyBwcm90b2NvbCBkZXZlbG9wbWVudCB3ZXJlIGNvbmZvdW5k ZWQgYnkgbGF0ZXIgZGVwbG95bWVudCBjb25kaXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij4mbmJzcDsgPC9zcGFuPuKAoiBTdXJ2ZXkgYSBzZXQgb2YgY2FzZXMgdG8gaWRlbnRpZnkgY29t bW9uIGZhY3RvcnMgaW4gdGhlc2UgY29uZm91bmRlZCBleHBlY3RhdGlvbnMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyA8L3NwYW4+4oCiIEV4cGxvcmUgcmVtZWRpYXRpb25zIHdoaWNo IGZvc3RlciB1c2VyIHByaXZhY3ksIHNlY3VyaXR5IGFuZCBwcm92aWRlciBkaXZlcnNpdHkgaW4g dGhlIGZhY2Ugb2YgdGhlc2UgY2hhbmdlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSW1wb3J0YW50IERhdGVzPGJyPg0KVGhlIHdvcmtz aG9wIHdpbGwgYmUgaGVsZCBKdW5lIDQtNSBpbiBIZWxzaW5raSwgRmlubGFuZC48YnI+DQpQb3Np dGlvbiBwYXBlcnMgbXVzdCBiZSBzdWJtaXR0ZWQgYnkgTWF5IDNyZCBhdCB0aGUgbGF0ZXN0LiBU aGUgcHJvZ3JhbSBjb21taXR0ZWUgd2lsbCByZXZpZXcgc3VibWl0dGVkIHBvc2l0aW9uIHBhcGVy cyBhbmQgc2VuZCBhbiBpbnZpdGF0aW9uIHRvIHRoZSB3b3Jrc2hvcCB0byBvbmUgb2YgdGhlIHBh cGVyIGF1dGhvcnMuIEludml0YXRpb25zIHdpbGwgYmUgZGlzdHJpYnV0ZWQgYnkgTWF5IDkgYXQg dGhlIGxhdGVzdC48YnI+DQpQb3NpdGlvbiBQYXBlciBSZXF1aXJlbWVudHM8YnI+DQpJbnRlcmVz dGVkIHBhcnRpZXMgbXVzdCBzdWJtaXQgYSBicmllZiBkb2N1bWVudCBvZiBvbmUgdG8gZm91ciBw YWdlcywgZm9ybWF0dGVkIGFzIEhUTUwsIFBERiwgb3IgcGxhaW4gdGV4dC4gV2Ugd2VsY29tZSBw YXBlcnMgdGhhdCBkZXNjcmliZSBleGlzdGluZyB3b3JrLCBhbnN3ZXJzIHRvIHRoZSBxdWVzdGlv bnMgbGlzdGVkIGFib3ZlLCBuZXcgcXVlc3Rpb25zLCB3cml0ZS11cHMgb2YgZGVwbG95bWVudCBl eHBlcmllbmNlLCBsZXNzb25zLWxlYXJuZWQNCiBmcm9tIHN1Y2Nlc3NmdWwgb3IgZmFpbGVkIGF0 dGVtcHRzLCBhbmQgaWRlYWxseSBhIHZpc2lvbiB0b3dhcmRzIHRha2luZyBkZXBsb3ltZW50IGNv bnNpZGVyYXRpb25zIGJldHRlciBpbiBhY2NvdW50IHdoZW4gZGVzaWduaW5nIG5ldyBJbnRlcm5l dCB0ZWNobm9sb2d5LiBSZS1zdWJtaXNzaW9ucyBmcm9tIHdvcmsgcHJlc2VudGVkIGVsc2V3aGVy ZSBhcmUgYWxsb3dlZC48YnI+DQpQcm9ncmFtIENvbW1pdHRlZTxicj4NClRoZSBmb2xsb3dpbmcg cGVyc29ucyBhcmUgSUFCIGNvbnRhY3RzIGZvciB0aGlzIHdvcmtzaG9wOjxicj4NCiZuYnNwOyAm bmJzcDsmbmJzcDtKYXJpIEFya2tvPGJyPg0KJm5ic3A7ICZuYnNwOyZuYnNwO1N0ZXBoZW4gRmFy cmVsbDxicj4NCiZuYnNwOyAmbmJzcDsmbmJzcDtUZWQgSGFyZGllPGJyPg0KJm5ic3A7ICZuYnNw OyZuYnNwO0NocmlzdGlhbiBIdWl0ZW1hPGJyPg0KJm5ic3A7ICZuYnNwOyZuYnNwO01lbGluZGEg U2hvcmU8YnI+DQombmJzcDsgJm5ic3A7Jm5ic3A7QnJpYW4gVHJhbW1lbGw8YnI+DQpQb3NpdGlv biBwYXBlcnMgc2hvdWxkIGJlIHNlbnQgYnkgZW1haWwgdG8mbmJzcDs8YSBocmVmPSJtYWlsdG86 ZGVkci1wY0BpYWIub3JnIj5kZWRyLXBjQGlhYi5vcmc8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWptPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+TWFyaWUtSm9zZSBNb250cGV0aXQsIFBoLkQuPGJyPg0KPGEg aHJlZj0ibWFpbHRvOm1hcmllam9AbWl0LmVkdSI+bWFyaWVqb0BtaXQuZWR1PC9hPjxicj4NCjxh IGhyZWY9Im1haWx0bzptYXJpZUBtam1vbnRwZXRpdC5jb20iPm1hcmllQG1qbW9udHBldGl0LmNv bTwvYT48YnI+DQomIzQzOzEtNzgxLTUyNi0yNjYxPGJyPg0KQFNvY2lhbFRWTUlUPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2Yg dGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBh bHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3Nl IHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl LA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM6PR08MB3686A132DFD5A4F6C3E4FFAAFA2B0AM6PR08MB3686eurp_-- From nobody Mon Apr 15 11:38:42 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732561200D8 for ; Mon, 15 Apr 2019 11:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV_LQIw8rCgM for ; Mon, 15 Apr 2019 11:38:37 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA85B120046 for ; Mon, 15 Apr 2019 11:38:37 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id n11so15458668ioh.1 for ; Mon, 15 Apr 2019 11:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=FAo+swbpbs9cdML1z7iEVaCtQm+cUTSdPGVLMdl9wxI=; b=kxnk9pQ+klmQHS3lRV4t8Jlu1keqTzKGk0+R7ipKd2bBpEN6XyLtysF+OvZ7hLuxtV LUBHr3n1IwYfW887BIwG8JtJid803McWp07DylRvbXMTR56sCJPT5T8sbf25lMGHVIMJ 9HYRrMTL6jSscazrIkF/6cWQuvNSppEmb5qykaite+hYCCk3iwH7OBrqWTv31C+UVFUI KpWH2Lfli5iEP+ZoJoR1ksNIFCZU1Wm/TH/+TcGH4CiR4ImR+v54GJJJT/p+y+evI8FE IrRJO/Uk36x47s9ry44U9fg93NqKHsQNppP3BotjDtl6MFG+lez+63CGoNHre5eMZQD+ /ccw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FAo+swbpbs9cdML1z7iEVaCtQm+cUTSdPGVLMdl9wxI=; b=Agi3os7XA7nc49860SQvO/zgHDWD69lQK2eBBkWl5J60BxzkY9yDVE9qTQfp5OZhEq COwTo0CyiwcMWdu75fwwFFutE5FQFQ8IYLdyuZd5m3/5BnE8Y0qLE0OeNVzj5WUqiGJG qXX0HyZZ3KR3MJ+BvBSt1+XnHCPSgsCFg7gjtw0JjLpQ9S/5p3RWa+uPUb5c4dExjXDb OpBZ/x92e/TOXkzGkCTcFm3s+XZs0DomX5CwsJb2qmJlGR3Aj+jZS0aTRJysxpILjF3G UtL5kBS3h+oygfspgBo3haTjG0VR6ony6Y2W4Md8+R9YVL1m0+XIHTYo/qD65EpxX9TH d70w== X-Gm-Message-State: APjAAAXnN1HzSim3rKo6Rm1KvxZZifgZfP6tWjgUgsFD5BNwxn1hyS+V isS7WZc+ThG6bHGn5JM7fsy/mJ5x X-Google-Smtp-Source: APXvYqxXNC93+GgK+xrA2R3r8ic0y/pN6qmgK0Noi/2h1NWXs/s/ZEYL+FFqS85etj2vv5keNMmzFQ== X-Received: by 2002:a6b:3f86:: with SMTP id m128mr42542944ioa.275.1555353516848; Mon, 15 Apr 2019 11:38:36 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id q8sm17826498ioi.33.2019.04.15.11.38.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Apr 2019 11:38:36 -0700 (PDT) To: =?UTF-8?Q?G=c3=b6ran_Selander?= , "secdispatch@ietf.org" References: <155507882604.16959.2935532240318784994.idtracker@ietfa.amsl.com> From: Rene Struik Message-ID: <7a604b70-1c6a-e799-f30c-c9369e62d8d0@gmail.com> Date: Mon, 15 Apr 2019 14:38:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Secdispatch] brief feedback on draft-selander-lake-reqs-00 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 18:38:41 -0000 Dear Goran: Some brief remarks on draft-selander-lake-reqs: a) duty cycle (see Section 4.2.1 - LoRaWaN): Duty cycle depends on context (e.g., duty cycle during Tx of a single frame is always 100%). According to ETSI [1], Section 5.4.1, duty cycle is relative to observation time window (Tobs) of 1 hour, where conformance ([1], Section 5.4.2), is defined relative to normal use during operational lifetime, where "the representative period shall be the most active one in normal use of the device. As a guide "Normal use" is considered as representing the behaviour of the device during transmission of 99 % of transmissions generated during its operational lifetime", and where "Procedures such as setup, commissioning and maintenance are not considered part of normal operation". This does suggest that inter-frame spacing is not necessarily 99 frames for each frame sent, as this section seems to claim. In fact, if key agreement is only done as part of network formation, it falls outside the duty cycle regulatory requirement. b) few messages/few frames (Section 4.2 - Discussion): The suggestion that a 3-message protocol is a requirement seems to be more an opinion/preference by the author, since lacking detailed technical justification. {If sending an additional frame causes "the probability of errors [to] increase exponentially", the medium access control layer seems to be unfit for use. Or, do you mean that if error probability is p, one gets prob no error in t frames equals (1-p)^t? If so, with small p with viable networks and small t, one definitely has (1-p)^t ~ 1 - t*p (i.e., almost linear degradation rather than the more dramatically sounding exponential).} c) conflicting requirements (Section 4.1 - AKE for OSCORE vs. Section 4.2 - Lightweight): There are trade-offs between communication overhead and security properties, which generally should be explored in more detail before imposing a requirement. As an example, a strict requirement for PFS may necessitate increased communication overhead, since, e.g., a communication failure during an AKC-scheme with strict PFS may preclude reusing this keying material with a retry mechanism. d) security considerations (Section 6): Contrary to what is suggested, the document is mostly about "size" arguments and does not offer a definition of desired algorithmic and operational security properties for sensor networks. e) protocol flavors (Section 2): The suggested protocol options include authenticated key agreement using symmetric-key, raw public keys, and certified public keys. Another option, which may be worth exploring (even if discarded based on sound rationale) is a key agreement scheme where authentication is based on a short secret authentication string (password) or a short public authentic, yet not secret string that is provided by a user (see, e.g., [3]). f) COSE algorithms (Section 4.1): The algorithms in the current COSE specification (RFC 8152) may not have a rich enough set of primitives to instantiate the sought after authenticated key agreement protocol. As an example, to my understanding, COSE only facilitates use of static-ephemeral co-factor Diffie-Hellman. Thus, some changes to the COSE specification may be required if one wishes to use a protocol that uses co-factor Diffie-Hellman based on ephemeral key shares. (Of course, this may be easily facilitated, esp. if the underlying core crypto primitive is already defined). These comments illustrate that some requirements are less clear-cut than as suggested in draft-selander-lake-reqs-00 and, that, in fact, there may be more to this than just a "smaller is always better" argument. Rene Ref: [1] ETSI EN 300 220-1 V3.1.1 (2017-02); [2] ETSI EN 300 220-2 V3.1.1 (2017-02); [3] Authenticated Key Agreement - Using Short Authenticated Strings (Serge Vaudenay, Crypto 2005) On 4/12/2019 12:20 PM, Göran Selander wrote: > On request I compiled the requirements for the lightweight AKE for OSCORE discussed on the list into a draft. This is not exactly the formulation by the security ADs but the main requirements should be there. > > Göran > > On 2019-04-12, 16:20, "internet-drafts@ietf.org" wrote: > > > A new version of I-D, draft-selander-lake-reqs-00.txt > has been successfully submitted by Göran Selander and posted to the > IETF repository. > > Name: draft-selander-lake-reqs > Revision: 00 > Title: Requirements for a Lightweight AKE for OSCORE. > Document date: 2019-04-12 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-selander-lake-reqs-00.txt > Status: https://datatracker.ietf.org/doc/draft-selander-lake-reqs/ > Htmlized: https://tools.ietf.org/html/draft-selander-lake-reqs-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-selander-lake-reqs > > > Abstract: > This document contains the requirements for a lightweight > authenticated key exchange protocol for OSCORE. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Mon Apr 15 13:48:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA15C12040E for ; Mon, 15 Apr 2019 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ObrRq8j1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XT9SMu/m Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61BP-yAB1KeH for ; Mon, 15 Apr 2019 13:47:58 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E6E12040C for ; Mon, 15 Apr 2019 13:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10288; q=dns/txt; s=iport; t=1555361278; x=1556570878; h=from:to:cc:subject:date:message-id:mime-version; bh=WKkR8ViyZscHDBZTZgV7cj3uojch/JztrZqDLW0qP5Q=; b=ObrRq8j16jwxMRnjSRnNUjElo+UMwyu3RSAkngh5Gzuko9GJi7/lFncH aAEamm+OGKwab5xiJa9EIsZpgzCnS07X0b7KobgTpBiMKmO0QXfq3AiJh dBkbwhHaoNKYjZjONGW/sU2C+IxvZdeU1mISodCLmhkEx397wuhsaB0Xg U=; IronPort-PHdr: =?us-ascii?q?9a23=3A38obdxUzy0R9fkUITx3kjtnVtobV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank9Et5DWVtN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAABw7bRc/5pdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBDi8pJwNoVSAECygKhASDRwOPF4JXkk+ES4E?= =?us-ascii?q?ugSQDVA4BAS2EQAIXhWMjNQgOAQMBAQoBAgECbRwMhUoBAQICASMKEwEBNwE?= =?us-ascii?q?EDQEIGCcDAgQwFBIBBAENBQiDG4EdTAMNDwGeNAKKFHGBL4J5AQEFhQAYgg0?= =?us-ascii?q?JgTIBi0kXgUA/gVeCTD6CYQSBYRWCczGCJo0phDmUUwkCggWSMZRzi2aUGwI?= =?us-ascii?q?EAgQFAg4BAQWBUQE1gVZwFYMnggqBJAEJgkGKU3KBKY4oAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.60,355,1549929600"; d="scan'208,217";a="259208501" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Apr 2019 20:47:57 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x3FKlvMA014666 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Apr 2019 20:47:57 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Apr 2019 15:47:57 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Apr 2019 15:47:56 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 15 Apr 2019 15:47:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WKkR8ViyZscHDBZTZgV7cj3uojch/JztrZqDLW0qP5Q=; b=XT9SMu/mQ5m8bqfu40B0LVbv7ggUL4UfjBKddfMQzxRb8ZA9YHrwvfAJFU7Of/M95Dv07XV6yAD4RCBbizOdgol10gFEFxR0Jp/EpESmK/kLJxyHqyeNitR8BDVW/NAKzbtbdr1Eksa3ATN2H3/zQivk2KeNIMiaGir4m4WEB+A= Received: from CY4PR11MB1541.namprd11.prod.outlook.com (10.172.68.150) by CY4PR11MB1527.namprd11.prod.outlook.com (10.172.70.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Mon, 15 Apr 2019 20:47:55 +0000 Received: from CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::eda2:f25e:1e10:16a4]) by CY4PR11MB1541.namprd11.prod.outlook.com ([fe80::eda2:f25e:1e10:16a4%2]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 20:47:55 +0000 From: "Owen Friel (ofriel)" To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Richard Barnes" , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: Re: [Secdispatch] EDHOC Summary Thread-Index: AdTzyofk3GE/98irTDSVd9BUcvG+cw== Date: Mon, 15 Apr 2019 20:47:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be693c38-c185-42b4-dabe-08d6c1e3a2a6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR11MB1527; x-ms-traffictypediagnostic: CY4PR11MB1527: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(376002)(136003)(396003)(189003)(199004)(8936002)(97736004)(8676002)(6436002)(5660300002)(55016002)(6306002)(256004)(4326008)(9686003)(14454004)(54896002)(86362001)(14444005)(68736007)(7736002)(66066001)(316002)(25786009)(33656002)(478600001)(6246003)(81156014)(53936002)(81166006)(52536014)(74316002)(229853002)(2906002)(486006)(476003)(110136005)(3846002)(790700001)(106356001)(105586002)(6116002)(7696005)(54906003)(99286004)(26005)(186003)(6506007)(102836004)(66574012)(53546011)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1527; H:CY4PR11MB1541.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1QWHkYsJPlVZ3H9HpdL32Mkk8PfHhveDeHo/6z++YFuDQs+WlzQ10UEpvzpjUIwDXNOtH3W0/jR7jKFbk08mSyLbMG/sp+4vaQvyFFTFioeoknXT/MMZS4almRWKmCAJTaScGiWM2PVCodSG99RGRlOvyc90RRmnYvjAoNgmKB5ASjTRlQ5IibihVMIo9V39Sz6BB30QcGFZ7FriAr1E2GGOp+75kQAEYFeUD7pc0McoX2faFR6iGVgr4zs1hcNe1KcSPFhpirDiDU+9DIUy+epy/i1WgYrx0eIE5T1jp4CEqHlY9pW44SJ92+0ukMBbW5Dbs87dzjmQ1E/TtJRSR8TRPM9IHIdN84vfLLSRy1ROLJWbrF5TtTCeETA7FFEdmSyipWhEaC/jELtHN6fMFmPYWNEWhirC8ol5mbKWSnI= Content-Type: multipart/alternative; boundary="_000_CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0CY4PR11MB1541namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: be693c38-c185-42b4-dabe-08d6c1e3a2a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 20:47:54.8923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1527 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 20:48:01 -0000 --_000_CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0CY4PR11MB1541namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgYXMgaWYgYSBwYXRoIGZvcndhcmQgaXMgYSBuZXcgTEFLRSBXRywgbm90IGEgc3Bl Y2lmaWMgRURIT0MgV0cuIEl0cyBwcmV0dHkgdW5hbmltb3VzIGFuZCB1bmNvbnRyb3ZlcnNpYWwg dGhhdCBhIGxpZ2h0d2VpZ2h0IEFLRSBpcyBuZWVkZWQgZm9yIGNvbnN0cmFpbmVkIG5ldHdvcmtz LiBFREhPQyBhbmQgY1RMUyBhcmUgdHdvIGNhbmRpZGF0ZSBMQUtFcywgYnV0IG5laXRoZXIgaXMg YSBwcmVkZXRlcm1pbmVkIHN0YXJ0aW5nIHBvaW50LCBsZXQgYWxvbmUgd2lubmVyLCB5ZXQuDQoN Ck9uIDEyLzA0LzIwMTkgMDA6MDgsIEfDtnJhbiBTZWxhbmRlciB3cm90ZToNCj4gSGkgUmljaGFy ZCwNCj4NCj4g77u/T24gMjAxOS0wNC0xMSwgMjE6MjEsICJSaWNoYXJkIEJhcm5lcyIgPHJsYkBp cHYuc3g+IHdyb3RlOg0KPg0KPiAgICAgT24gVGh1LCBBcHIgMTEsIDIwMTkgYXQgMzoxNSBQTSBN aWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYSA8bWFpbHRvOm1jciUyQmll dGZAc2FuZGVsbWFuLmNhPj4gd3JvdGU6DQo+DQo+DQo+ICAgICBSaWNoYXJkIEJhcm5lcyA8cmxi QGlwdi5zeD4gd3JvdGU6DQo+ICAgICAgICAgPiBJJ2QgbGlrZSB0byBwdXNoIGJhY2sgb24gdGhp cyBwb2ludC4gSXQgbWF5IGJlIHRoYXQgRURIT0MgaGFzIGJlZW4gYXJvdW5kIGZvcg0KPiAgICAg ICAgID4gYSB3aGlsZSBhbmQgYmVlbiB3ZWxsLXNvY2lhbGl6ZWQgd2l0aCB0aGUgSW9UIGNyb3dk LCBidXQgaXQgaXMgY2xlYXJseQ0KPiAgICAgICAgID4gZGVmaWNpZW50IGluIHNldmVyYWwgb3Ro ZXIgdHlwZXMgb2YgbWF0dXJpdHksIGUuZy4sIHJvYnVzdG5lc3Mgb2YgZm9ybWFsDQo+ICAgICAg ICAgPiBhbmFseXNlcyBhbmQgc3RhdGUgb2YgaW1wbGVtZW50YXRpb25zIChBRkFJQ1QpLg0KPg0K PiAgICAgSSB3YW50IHRvIGJlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgeW91Lg0KPg0KPiAgICAg SXMgaXQgeW91ciBvcGluaW9uIHRoYSB0aGUgSUVURiBjYW4gbm90IGZvcm0gYSBXRyB1bnRpbCBh ZnRlciBhIHByb3RvY29sIGhhcw0KPiAgICAgaGFkIGZvcm1hbCBhbmFseXNpcz8gIEhvdyBtYW55 IGFuYWx5c2lzPyAgSG93IG1hbnkgeWVhcnM/ICBXaGljaCBwdWJsaWNhdGlvbnM/DQo+DQo+DQo+ ICAgICBJIGRpZG4ndCBtZWFuIGFueXRoaW5nIHcuci50LiB0aGUgZm9ybWF0aW9uIG9mIGEgV0cu ICBDYXJzdGVuJ3MgaW1wbGljYXRpb24gc2VlbWVkIHRvIGJlIHRoYXQgYW4gRURIT0MgV0cgY291 bGQgZGVsaXZlciBtb3JlIHF1aWNrbHkgdGhhbiwgZS5nLiwgb25lIHVzaW5nIFRMUyBhcyBhIHN0 YXJ0aW5nIHBvaW50LiAgVGhhdCdzIHRoZSBwb2ludCBJIHdhcyBwdXNoaW5nIGJhY2sgb24gLS0g SSBob3BlIHdlIGFncmVlIHRoYXQgZGVsaXZlcmluZw0KPiAgICAgIGEgZmluYWwgc2VjdXJpdHkg cHJvdG9jb2wgc2hvdWxkIGJlIGdhdGVkIG9uIHJvYnVzdCBhbmFseXNpcyBhbmQgbXVsdGlwbGUg aW1wbGVtZW50YXRpb25zLg0KPg0KPiBbR1NdIEFzIEkgbWVudGlvbmVkIGluIG15IHJlY2VudCBy ZXBseSwgZ2l2ZW4gdGhlIGNoYW5nZXMgeW91IG1ha2UgdG8gVExTIHRvIG1ha2UgbWVzc2FnZSBz aXplcyBvbiBwYXIgd2l0aCBFREhPQywgaXQgaXMgYSBuZXcgcHJvdG9jb2wgc28gdGhlIHN0YXRl bWVudCBhYm91dCByZWx5aW5nIG9uIHRoZSBhbmFseXNpcyBvZiBUTFMgaXMgcXVlc3Rpb25hYmxl LiBDb21wYXJpbmcgaW1wbGVtZW50YXRpb25zIHRoZXJlIGFyZSBjbGVhcmx5IG1vcmUgb2YgVExT LCBidXQsIGFnYWluLCB0aGlzIGlzIGEgbmV3IHByb3RvY29sLg0KPg0KPiBHw7ZyYW4NCj4NCj4N Cj4NCj4gICAgIC0tUmljaGFyZA0KZ3JzZGZzZGYNCg== --_000_CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0CY4PR11MB1541namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyBhcyBpZiBh IHBhdGggZm9yd2FyZCBpcyBhIG5ldyBMQUtFIFdHLCBub3QgYSBzcGVjaWZpYyBFREhPQyBXRy4g SXRzIHByZXR0eSB1bmFuaW1vdXMgYW5kIHVuY29udHJvdmVyc2lhbCB0aGF0IGEgbGlnaHR3ZWln aHQgQUtFIGlzIG5lZWRlZCBmb3IgY29uc3RyYWluZWQgbmV0d29ya3MuIEVESE9DIGFuZCBjVExT IGFyZSB0d28gY2FuZGlkYXRlIExBS0VzLCBidXQgbmVpdGhlciBpcyBhIHByZWRldGVybWluZWQN CiBzdGFydGluZyBwb2ludCwgbGV0IGFsb25lIHdpbm5lciwgeWV0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAxMi8wNC8yMDE5IDAwOjA4LCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEhpIFJpY2hhcmQsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IO+7v09uIDIwMTktMDQtMTEsIDIxOjIxLCAmcXVvdDtS aWNoYXJkIEJhcm5lcyZxdW90OyAmbHQ7cmxiQGlwdi5zeCZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIFRodSwgQXBy IDExLCAyMDE5IGF0IDM6MTUgUE0gTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3ImIzQzO2lldGZA c2FuZGVsbWFuLmNhICZsdDttYWlsdG86bWNyJTJCaWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSaWNoYXJkIEJhcm5lcyAmbHQ7cmxi QGlwdi5zeCZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg SSdkIGxpa2UgdG8gcHVzaCBiYWNrIG9uIHRoaXMgcG9pbnQuIEl0IG1heSBiZSB0aGF0IEVESE9D IGhhcyBiZWVuIGFyb3VuZCBmb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBhIHdoaWxlIGFuZCBiZWVuIHdlbGwtc29jaWFsaXplZCB3aXRoIHRoZSBJb1QgY3Jvd2QsIGJ1 dCBpdCBpcyBjbGVhcmx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZGVm aWNpZW50IGluIHNldmVyYWwgb3RoZXIgdHlwZXMgb2YgbWF0dXJpdHksIGUuZy4sIHJvYnVzdG5l c3Mgb2YgZm9ybWFsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYW5hbHlz ZXMgYW5kIHN0YXRlIG9mIGltcGxlbWVudGF0aW9ucyAoQUZBSUNUKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEkgd2FudCB0byBiZSBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIHlvdS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IElzIGl0IHlvdXIgb3BpbmlvbiB0aGEgdGhlIElFVEYgY2FuIG5vdCBmb3JtIGEgV0cg dW50aWwgYWZ0ZXIgYSBwcm90b2NvbCBoYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFkIGZvcm1hbCBhbmFseXNpcz8m bmJzcDsgSG93IG1hbnkgYW5hbHlzaXM/Jm5ic3A7IEhvdyBtYW55IHllYXJzPyZuYnNwOyBXaGlj aCBwdWJsaWNhdGlvbnM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBkaWRuJ3QgbWVh biBhbnl0aGluZyB3LnIudC4gdGhlIGZvcm1hdGlvbiBvZiBhIFdHLiZuYnNwOyBDYXJzdGVuJ3Mg aW1wbGljYXRpb24gc2VlbWVkIHRvIGJlIHRoYXQgYW4gRURIT0MgV0cgY291bGQgZGVsaXZlciBt b3JlIHF1aWNrbHkgdGhhbiwgZS5nLiwgb25lIHVzaW5nIFRMUyBhcyBhIHN0YXJ0aW5nIHBvaW50 LiZuYnNwOyBUaGF0J3MgdGhlIHBvaW50IEkgd2FzIHB1c2hpbmcgYmFjayBvbiAtLSBJIGhvcGUN CiB3ZSBhZ3JlZSB0aGF0IGRlbGl2ZXJpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBmaW5hbCBzZWN1cml0 eSBwcm90b2NvbCBzaG91bGQgYmUgZ2F0ZWQgb24gcm9idXN0IGFuYWx5c2lzIGFuZCBtdWx0aXBs ZSBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFtHU10g QXMgSSBtZW50aW9uZWQgaW4gbXkgcmVjZW50IHJlcGx5LCBnaXZlbiB0aGUgY2hhbmdlcyB5b3Ug bWFrZSB0byBUTFMgdG8gbWFrZSBtZXNzYWdlIHNpemVzIG9uIHBhciB3aXRoIEVESE9DLCBpdCBp cyBhIG5ldyBwcm90b2NvbCBzbyB0aGUgc3RhdGVtZW50IGFib3V0IHJlbHlpbmcgb24gdGhlIGFu YWx5c2lzIG9mIFRMUyBpcyBxdWVzdGlvbmFibGUuIENvbXBhcmluZyBpbXBsZW1lbnRhdGlvbnMg dGhlcmUNCiBhcmUgY2xlYXJseSBtb3JlIG9mIFRMUywgYnV0LCBhZ2FpbiwgdGhpcyBpcyBhIG5l dyBwcm90b2NvbC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEfDtnJhbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS1S aWNoYXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncnNkZnNkZjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0CY4PR11MB1541namp_-- From nobody Tue Apr 16 00:18:44 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177F41201B3 for ; Tue, 16 Apr 2019 00:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=armh.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 YUPvoAjJItgR for ; Tue, 16 Apr 2019 00:18:38 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10064.outbound.protection.outlook.com [40.107.1.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B69B120346 for ; Tue, 16 Apr 2019 00:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KrNh+/jhubLICUQVWtREMtnAVJhIJ6x6ogZFaHj+PMc=; b=WdEaxg9fPP0nF6LTIxM1U+sgJM9JURCuzGyUwNq8SdY/ONI+Qp96ZJec5iVvarDBXoNejwXLYRQZOZ4VSreZd0WejhNtWc/FCf5CCpO+CfgmatNBDrT7TY0mdI5zdlb4zuLKP/rRwyOSa8edvM9SVloi7lIIV1kymfk+ggWkdLI= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3350.eurprd08.prod.outlook.com (52.135.165.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Tue, 16 Apr 2019 07:18:33 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 07:18:33 +0000 From: Hannes Tschofenig To: "Owen Friel (ofriel)" , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: Re: [Secdispatch] EDHOC Summary Thread-Index: AdTzyofk3GE/98irTDSVd9BUcvG+cwAWPHFQ Date: Tue, 16 Apr 2019 07:18:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7b482782-77d9-41a1-6682-08d6c23bbc63 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3350; x-ms-traffictypediagnostic: AM6PR08MB3350: x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(376002)(39860400002)(366004)(199004)(189003)(40434004)(229853002)(6246003)(99286004)(9686003)(6436002)(236005)(26005)(53936002)(14444005)(71200400001)(68736007)(5024004)(54896002)(256004)(55016002)(6306002)(316002)(54906003)(66574012)(110136005)(71190400001)(102836004)(66066001)(446003)(11346002)(476003)(86362001)(97736004)(14454004)(33656002)(478600001)(486006)(105586002)(186003)(7696005)(81156014)(25786009)(4326008)(81166006)(106356001)(8936002)(8676002)(2906002)(52536014)(76176011)(7736002)(3846002)(5660300002)(74316002)(790700001)(6116002)(6506007)(53546011)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3350; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oiQS6pjJQyLZ6UJZaT6F0zLxARz89ftVTMwuYHtOeW7uuqtGD6Oir9CILy9M2Iex5BW5p0i+ksxUv4sB+0Vgp92Qgt5dKA1Byp/YFgKl/gvLqk1Ll0dCg1w30Xh2ZcqO0xvBI7O9TKlxD0c0zmwF8JP30XPbi6N9zgHRkvm+24Gce3tYk3fLENz/9UG1QzMD+gef1JDkvSqaXFmtLAX+ghFbQt+KJFLdYu/u61TSUlcL3coFA5pv6xNmhdbb0+P3n79B3Q7q4O2RD9KbEo+T6RLBJcQQkE14wO5QGadvgEhAa8HPvflu2NAi9Ce6ymA7IhkN55wOgBO/RPS06jeZtJaj35noL3YxuBd964fl7OqQhS96ikqoIGMNSS9hwjPs+wanMkhO85MaogwRB3wZH+987hZbn6JljfwFpIOnExI= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB368674B7799F15E103389E9AFA240AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b482782-77d9-41a1-6682-08d6c23bbc63 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 07:18:33.7993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3350 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:18:43 -0000 --_000_AM6PR08MB368674B7799F15E103389E9AFA240AM6PR08MB3686eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T3dlbiwgSSBhbSBmaW5lIHdpdGggY3JlYXRpbmcgYSBuZXcgd29ya2luZyBncm91cCBhcyB5b3Ug c3VnZ2VzdGVkIGJlbG93IHRvIHdvcmsgb24gYSBsaWdodHdlaWdodCBBS0EuDQoNCkhvd2V2ZXIs IEkgbmVlZCB0byBzdGF0ZSB0aGF0IHRoZXJlIGlzbuKAmXQgZXZlbiBhIHByb2JsZW0gd2l0aCBE VExTL1RMUyAxLjIgaW4gSW9UIG5ldHdvcmtzLiBUaGUgaGFuZHNoYWtlIGl0c2VsZiBpcyBzdWNo IGEgc21hbGwgcGFydCBvZiB0aGUgb3ZlcmFsbCBjb21tdW5pY2F0aW9uIGluIHRoZSBsaWZlIG9m IGFuIElvVCBkZXZpY2UgdGhhdCBmb2N1c2luZyB0aGUgb3B0aW1pemF0aW9uIGVmZm9ydHMgb24g dGhlIGhhbmRzaGFrZSBpcyBhbG1vc3QgcmlkaWN1bG91cy4gT2YgY291cnNlLCBubyBwcm90b2Nv bCBkZXNpZ25lciB3YW50cyB0byBoZWFyIHRoYXQgdGhlcmUgYXJlIHN5c3RlbSBhc3BlY3RzIHRo YXQgcGxheSBhIG11Y2ggYmlnZ2VyIHJvbGUgaW4gcmVkdWNpbmcgcG93ZXIgY29uc3VtcHRpb24u DQoNCklmIHlvdSBjb25zaWRlciB0aGF0IHRoZSB0b3AgSW9UIGNvbXBhbmllcyB1c2UgTVFUVCBw cm90ZWN0ZWQgd2l0aCBUTFMgdXNpbmcgY2VydGlmaWNhdGVzIHRvZGF5IGluIHRoZWlyIGxhcmdl IGRlcGxveW1lbnQgdG9kYXkgdGhlbiB5b3UgbWlnaHQgZXZlbiB3b25kZXJpbmcgd2hlcmUgdGhl IGxhcmdlIGRpc2Nvbm5lY3QgY29tZXMgZnJvbS4NCg0KRnJvbTogU2VjZGlzcGF0Y2ggPHNlY2Rp c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBPd2VuIEZyaWVsIChvZnJpZWwp DQpTZW50OiBNb250YWcsIDE1LiBBcHJpbCAyMDE5IDIyOjQ4DQpUbzogR8O2cmFuIFNlbGFuZGVy IDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+OyBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5z eD47IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KQ2M6IENhcnN0 ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgc2VjZGlzcGF0Y2hAaWV0Zi5vcmc7IE1hcnRpbiBU aG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4NClN1YmplY3Q6IFJlOiBbU2VjZGlzcGF0Y2hdIEVE SE9DIFN1bW1hcnkNCg0KSXQgc2VlbXMgYXMgaWYgYSBwYXRoIGZvcndhcmQgaXMgYSBuZXcgTEFL RSBXRywgbm90IGEgc3BlY2lmaWMgRURIT0MgV0cuIEl0cyBwcmV0dHkgdW5hbmltb3VzIGFuZCB1 bmNvbnRyb3ZlcnNpYWwgdGhhdCBhIGxpZ2h0d2VpZ2h0IEFLRSBpcyBuZWVkZWQgZm9yIGNvbnN0 cmFpbmVkIG5ldHdvcmtzLiBFREhPQyBhbmQgY1RMUyBhcmUgdHdvIGNhbmRpZGF0ZSBMQUtFcywg YnV0IG5laXRoZXIgaXMgYSBwcmVkZXRlcm1pbmVkIHN0YXJ0aW5nIHBvaW50LCBsZXQgYWxvbmUg d2lubmVyLCB5ZXQuDQoNCk9uIDEyLzA0LzIwMTkgMDA6MDgsIEfDtnJhbiBTZWxhbmRlciB3cm90 ZToNCj4gSGkgUmljaGFyZCwNCj4NCj4g77u/T24gMjAxOS0wNC0xMSwgMjE6MjEsICJSaWNoYXJk IEJhcm5lcyIgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCj4NCj4gICAg IE9uIFRodSwgQXByIDExLCAyMDE5IGF0IDM6MTUgUE0gTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2EgPG1haWx0bzptY3IlMkJpZXRmQHNhbmRlbG1hbi5jYTxtYWlsdG86 bWNyK2lldGZAc2FuZGVsbWFuLmNhJTIwJTNjbWFpbHRvOm1jciUyQmlldGZAc2FuZGVsbWFuLmNh Pj4+IHdyb3RlOg0KPg0KPg0KPiAgICAgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRv OnJsYkBpcHYuc3g+PiB3cm90ZToNCj4gICAgICAgICA+IEknZCBsaWtlIHRvIHB1c2ggYmFjayBv biB0aGlzIHBvaW50LiBJdCBtYXkgYmUgdGhhdCBFREhPQyBoYXMgYmVlbiBhcm91bmQgZm9yDQo+ ICAgICAgICAgPiBhIHdoaWxlIGFuZCBiZWVuIHdlbGwtc29jaWFsaXplZCB3aXRoIHRoZSBJb1Qg Y3Jvd2QsIGJ1dCBpdCBpcyBjbGVhcmx5DQo+ICAgICAgICAgPiBkZWZpY2llbnQgaW4gc2V2ZXJh bCBvdGhlciB0eXBlcyBvZiBtYXR1cml0eSwgZS5nLiwgcm9idXN0bmVzcyBvZiBmb3JtYWwNCj4g ICAgICAgICA+IGFuYWx5c2VzIGFuZCBzdGF0ZSBvZiBpbXBsZW1lbnRhdGlvbnMgKEFGQUlDVCku DQo+DQo+ICAgICBJIHdhbnQgdG8gYmUgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB5b3UuDQo+DQo+ ICAgICBJcyBpdCB5b3VyIG9waW5pb24gdGhhIHRoZSBJRVRGIGNhbiBub3QgZm9ybSBhIFdHIHVu dGlsIGFmdGVyIGEgcHJvdG9jb2wgaGFzDQo+ICAgICBoYWQgZm9ybWFsIGFuYWx5c2lzPyAgSG93 IG1hbnkgYW5hbHlzaXM/ICBIb3cgbWFueSB5ZWFycz8gIFdoaWNoIHB1YmxpY2F0aW9ucz8NCj4N Cj4NCj4gICAgIEkgZGlkbid0IG1lYW4gYW55dGhpbmcgdy5yLnQuIHRoZSBmb3JtYXRpb24gb2Yg YSBXRy4gIENhcnN0ZW4ncyBpbXBsaWNhdGlvbiBzZWVtZWQgdG8gYmUgdGhhdCBhbiBFREhPQyBX RyBjb3VsZCBkZWxpdmVyIG1vcmUgcXVpY2tseSB0aGFuLCBlLmcuLCBvbmUgdXNpbmcgVExTIGFz IGEgc3RhcnRpbmcgcG9pbnQuICBUaGF0J3MgdGhlIHBvaW50IEkgd2FzIHB1c2hpbmcgYmFjayBv biAtLSBJIGhvcGUgd2UgYWdyZWUgdGhhdCBkZWxpdmVyaW5nDQo+ICAgICAgYSBmaW5hbCBzZWN1 cml0eSBwcm90b2NvbCBzaG91bGQgYmUgZ2F0ZWQgb24gcm9idXN0IGFuYWx5c2lzIGFuZCBtdWx0 aXBsZSBpbXBsZW1lbnRhdGlvbnMuDQo+DQo+IFtHU10gQXMgSSBtZW50aW9uZWQgaW4gbXkgcmVj ZW50IHJlcGx5LCBnaXZlbiB0aGUgY2hhbmdlcyB5b3UgbWFrZSB0byBUTFMgdG8gbWFrZSBtZXNz YWdlIHNpemVzIG9uIHBhciB3aXRoIEVESE9DLCBpdCBpcyBhIG5ldyBwcm90b2NvbCBzbyB0aGUg c3RhdGVtZW50IGFib3V0IHJlbHlpbmcgb24gdGhlIGFuYWx5c2lzIG9mIFRMUyBpcyBxdWVzdGlv bmFibGUuIENvbXBhcmluZyBpbXBsZW1lbnRhdGlvbnMgdGhlcmUgYXJlIGNsZWFybHkgbW9yZSBv ZiBUTFMsIGJ1dCwgYWdhaW4sIHRoaXMgaXMgYSBuZXcgcHJvdG9jb2wuDQo+DQo+IEfDtnJhbg0K Pg0KPg0KPg0KPiAgICAgLS1SaWNoYXJkDQpncnNkZnNkZg0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM6PR08MB368674B7799F15E103389E9AFA240AM6PR08MB3686eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Pd2VuLCBJIGFtIGZpbmUgd2l0aCBjcmVh dGluZyBhIG5ldyB3b3JraW5nIGdyb3VwIGFzIHlvdSBzdWdnZXN0ZWQgYmVsb3cgdG8gd29yayBv biBhIGxpZ2h0d2VpZ2h0IEFLQS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Ib3dldmVyLCBJIG5lZWQgdG8gc3RhdGUgdGhh dCB0aGVyZSBpc27igJl0IGV2ZW4gYSBwcm9ibGVtIHdpdGggRFRMUy9UTFMgMS4yIGluIElvVCBu ZXR3b3Jrcy4gVGhlIGhhbmRzaGFrZSBpdHNlbGYgaXMgc3VjaCBhIHNtYWxsIHBhcnQgb2YgdGhl IG92ZXJhbGwgY29tbXVuaWNhdGlvbiBpbiB0aGUgbGlmZSBvZiBhbiBJb1QgZGV2aWNlIHRoYXQN CiBmb2N1c2luZyB0aGUgb3B0aW1pemF0aW9uIGVmZm9ydHMgb24gdGhlIGhhbmRzaGFrZSBpcyBh bG1vc3QgcmlkaWN1bG91cy4gT2YgY291cnNlLCBubyBwcm90b2NvbCBkZXNpZ25lciB3YW50cyB0 byBoZWFyIHRoYXQgdGhlcmUgYXJlIHN5c3RlbSBhc3BlY3RzIHRoYXQgcGxheSBhIG11Y2ggYmln Z2VyIHJvbGUgaW4gcmVkdWNpbmcgcG93ZXIgY29uc3VtcHRpb24uDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgeW91IGNv bnNpZGVyIHRoYXQgdGhlIHRvcCBJb1QgY29tcGFuaWVzIHVzZSBNUVRUIHByb3RlY3RlZCB3aXRo IFRMUyB1c2luZyBjZXJ0aWZpY2F0ZXMgdG9kYXkgaW4gdGhlaXIgbGFyZ2UgZGVwbG95bWVudCB0 b2RheSB0aGVuIHlvdSBtaWdodCBldmVuIHdvbmRlcmluZyB3aGVyZSB0aGUgbGFyZ2UgZGlzY29u bmVjdCBjb21lcyBmcm9tLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBTZWNkaXNwYXRjaCAmbHQ7c2VjZGlzcGF0 Y2gtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+T3dlbiBGcmllbCAo b2ZyaWVsKTxicj4NCjxiPlNlbnQ6PC9iPiBNb250YWcsIDE1LiBBcHJpbCAyMDE5IDIyOjQ4PGJy Pg0KPGI+VG86PC9iPiBHw7ZyYW4gU2VsYW5kZXIgJmx0O2dvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbSZndDs7IFJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2LnN4Jmd0OzsgTWljaGFlbCBSaWNo YXJkc29uICZsdDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0Ozxicj4NCjxiPkNjOjwvYj4g Q2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7OyBzZWNkaXNwYXRjaEBpZXRmLm9y ZzsgTWFydGluIFRob21zb24gJmx0O210QGxvd2VudHJvcHkubmV0Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1NlY2Rpc3BhdGNoXSBFREhPQyBTdW1tYXJ5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgYXMgaWYgYSBwYXRoIGZvcndh cmQgaXMgYSBuZXcgTEFLRSBXRywgbm90IGEgc3BlY2lmaWMgRURIT0MgV0cuIEl0cyBwcmV0dHkg dW5hbmltb3VzIGFuZCB1bmNvbnRyb3ZlcnNpYWwgdGhhdCBhIGxpZ2h0d2VpZ2h0IEFLRSBpcyBu ZWVkZWQgZm9yIGNvbnN0cmFpbmVkIG5ldHdvcmtzLiBFREhPQyBhbmQgY1RMUyBhcmUgdHdvIGNh bmRpZGF0ZSBMQUtFcywgYnV0IG5laXRoZXIgaXMgYSBwcmVkZXRlcm1pbmVkDQogc3RhcnRpbmcg cG9pbnQsIGxldCBhbG9uZSB3aW5uZXIsIHlldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MTIvMDQvMjAxOSAwMDowOCwgR8O2cmFuIFNlbGFuZGVyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBIaSBSaWNoYXJkLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyDvu79PbiAyMDE5LTA0LTExLCAyMToyMSwgJnF1b3Q7UmljaGFyZCBCYXJu ZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4Ij5ybGJAaXB2LnN4PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9uIFRodSwgQXByIDExLCAyMDE5IGF0IDM6MTUgUE0gTWljaGFlbCBSaWNoYXJk c29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSUyMCUzY21h aWx0bzptY3IlMkJpZXRmQHNhbmRlbG1hbi5jYSI+bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSAm bHQ7bWFpbHRvOm1jciUyQmlldGZAc2FuZGVsbWFuLmNhPC9hPiZndDsmZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpY2hhcmQgQmFybmVzICZsdDs8YSBocmVmPSJtYWls dG86cmxiQGlwdi5zeCI+cmxiQGlwdi5zeDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEknZCBsaWtlIHRvIHB1c2ggYmFjayBvbiB0aGlzIHBvaW50 LiBJdCBtYXkgYmUgdGhhdCBFREhPQyBoYXMgYmVlbiBhcm91bmQgZm9yPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYSB3aGlsZSBhbmQgYmVlbiB3ZWxsLXNvY2lhbGl6ZWQg d2l0aCB0aGUgSW9UIGNyb3dkLCBidXQgaXQgaXMgY2xlYXJseTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGRlZmljaWVudCBpbiBzZXZlcmFsIG90aGVyIHR5cGVzIG9mIG1h dHVyaXR5LCBlLmcuLCByb2J1c3RuZXNzIG9mIGZvcm1hbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IGFuYWx5c2VzIGFuZCBzdGF0ZSBvZiBpbXBsZW1lbnRhdGlvbnMgKEFG QUlDVCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIHdhbnQgdG8gYmUgc3VyZSB0aGF0IEkgdW5kZXJz dGFuZCB5b3UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJcyBpdCB5b3VyIG9waW5pb24gdGhhIHRoZSBJ RVRGIGNhbiBub3QgZm9ybSBhIFdHIHVudGlsIGFmdGVyIGEgcHJvdG9jb2wgaGFzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGhhZCBmb3JtYWwgYW5hbHlzaXM/Jm5ic3A7IEhvdyBtYW55IGFuYWx5c2lzPyZuYnNwOyBIb3cg bWFueSB5ZWFycz8mbmJzcDsgV2hpY2ggcHVibGljYXRpb25zPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEkgZGlkbid0IG1lYW4gYW55dGhpbmcgdy5yLnQuIHRoZSBmb3JtYXRpb24gb2Yg YSBXRy4mbmJzcDsgQ2Fyc3RlbidzIGltcGxpY2F0aW9uIHNlZW1lZCB0byBiZSB0aGF0IGFuIEVE SE9DIFdHIGNvdWxkIGRlbGl2ZXIgbW9yZSBxdWlja2x5IHRoYW4sIGUuZy4sIG9uZSB1c2luZyBU TFMgYXMgYSBzdGFydGluZyBwb2ludC4mbmJzcDsgVGhhdCdzIHRoZSBwb2ludCBJIHdhcyBwdXNo aW5nIGJhY2sgb24gLS0gSSBob3BlDQogd2UgYWdyZWUgdGhhdCBkZWxpdmVyaW5nPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGEgZmluYWwgc2VjdXJpdHkgcHJvdG9jb2wgc2hvdWxkIGJlIGdhdGVkIG9uIHJvYnVz dCBhbmFseXNpcyBhbmQgbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyBbR1NdIEFzIEkgbWVudGlvbmVkIGluIG15IHJlY2VudCByZXBseSwg Z2l2ZW4gdGhlIGNoYW5nZXMgeW91IG1ha2UgdG8gVExTIHRvIG1ha2UgbWVzc2FnZSBzaXplcyBv biBwYXIgd2l0aCBFREhPQywgaXQgaXMgYSBuZXcgcHJvdG9jb2wgc28gdGhlIHN0YXRlbWVudCBh Ym91dCByZWx5aW5nIG9uIHRoZSBhbmFseXNpcyBvZiBUTFMgaXMgcXVlc3Rpb25hYmxlLiBDb21w YXJpbmcgaW1wbGVtZW50YXRpb25zIHRoZXJlDQogYXJlIGNsZWFybHkgbW9yZSBvZiBUTFMsIGJ1 dCwgYWdhaW4sIHRoaXMgaXMgYSBuZXcgcHJvdG9jb2wuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyBHw7ZyYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tUmljaGFyZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Z3JzZGZzZGY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM6PR08MB368674B7799F15E103389E9AFA240AM6PR08MB3686eurp_-- From nobody Tue Apr 16 00:26:09 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69B120151 for ; Tue, 16 Apr 2019 00:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=armh.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 kOdOhkjVkX1C for ; Tue, 16 Apr 2019 00:26:05 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::618]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A8D120139 for ; Tue, 16 Apr 2019 00:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qah5DwCnq5wBRcnhpcEe2aD9JAawblxHKG3C89Ae5c4=; b=nVTRieAYAtVyTg7Mz11qUlvvf4BjAayilTdTSWrfGumABipqF4XLvT2L0L57ls0GedCAFOiGIQ5nrwg8rEHVRGn0u2clJnR1ZV2Lrru3P85imKe0i91Kas5pKEsuOvUsCtLYrzCMKbtBIaBT89SXwZkxm+rYHZ608CFjO/GXyoY= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4834.eurprd08.prod.outlook.com (10.255.98.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Tue, 16 Apr 2019 07:26:02 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 07:26:02 +0000 From: Hannes Tschofenig To: "Owen Friel (ofriel)" , =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: Re: [Secdispatch] EDHOC Summary Thread-Index: AdTzyofk3GE/98irTDSVd9BUcvG+cwAWhESw Date: Tue, 16 Apr 2019 07:26:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce294cd4-32ce-433c-e858-08d6c23cc78c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB4834; x-ms-traffictypediagnostic: AM6PR08MB4834: x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(346002)(39860400002)(136003)(40434004)(199004)(189003)(68736007)(256004)(106356001)(99286004)(8936002)(6116002)(14444005)(54896002)(33656002)(14454004)(790700001)(3846002)(54906003)(74316002)(53936002)(7736002)(102836004)(25786009)(7696005)(66066001)(6506007)(76176011)(9686003)(11346002)(236005)(26005)(55016002)(71190400001)(186003)(6306002)(4326008)(71200400001)(5024004)(6436002)(478600001)(316002)(8676002)(486006)(5660300002)(229853002)(86362001)(110136005)(6246003)(97736004)(81166006)(52536014)(476003)(105586002)(72206003)(2906002)(81156014)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4834; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lvmslMx3x5SQK7u4vxSbG5YMPZaXzRNTPKQUtY3WTEADpGwU14E9ezgOUlgrczabA9K5H1hbHLkKbzzL6BHRPj+B/7n3nJ7KQ9j1yWcqjmaEm6nVDrdQrGEoyMD49E/vYoOz6CBCJKa836nN1bfmMCtHZXfNnaXJ8KEZ+J63/ezzfMnSrRliozLYAgJsGCf2ZzYqwtzJUrKmdk7eQXZSBamQpjx1CtczIcMydhXqLFdheB/2rCO3WhHYsVM0jJtyHY2ntumQq6jOjDSsj9SR5RkQt5yX0orhCl6HSCNiK1q1qyz+MPAEI6PwZ9pBTUP6st8968k9/BqW+RQxrq7YzJLDspVxkyOwUswdGUM8Pyz8cNoX9K2hniaOKqMuKmfLrxn82Z0lJDD1w6e4L5R1QlU/B2f85rIZ5IjNuVtmfLc= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB36866DB97940341DB43D8331FA240AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce294cd4-32ce-433c-e858-08d6c23cc78c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 07:26:02.0920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4834 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 07:26:07 -0000 --_000_AM6PR08MB36866DB97940341DB43D8331FA240AM6PR08MB3686eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgICAgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90 ZToNCj4gICAgICAgICA+IEknZCBsaWtlIHRvIHB1c2ggYmFjayBvbiB0aGlzIHBvaW50LiBJdCBt YXkgYmUgdGhhdCBFREhPQyBoYXMgYmVlbiBhcm91bmQgZm9yDQo+ICAgICAgICAgPiBhIHdoaWxl IGFuZCBiZWVuIHdlbGwtc29jaWFsaXplZCB3aXRoIHRoZSBJb1QgY3Jvd2QsIGJ1dCBpdCBpcyBj bGVhcmx5DQo+ICAgICAgICAgPiBkZWZpY2llbnQgaW4gc2V2ZXJhbCBvdGhlciB0eXBlcyBvZiBt YXR1cml0eSwgZS5nLiwgcm9idXN0bmVzcyBvZiBmb3JtYWwNCj4gICAgICAgICA+IGFuYWx5c2Vz IGFuZCBzdGF0ZSBvZiBpbXBsZW1lbnRhdGlvbnMgKEFGQUlDVCkuDQoNCkkgd291bGQgbGlrZSB0 byBwb2ludCBvdXQgdGhhdCBpbml0aWFsbHkgdGhlIHdvcmsgb24gRURIT0Mgd2FzIGludGVudGlv bmFsbHkgbm90IHBvc2l0aW9uZWQgYXMgYSBUTFMgcmVwbGFjZW1lbnQgKG9yIGV2ZW4gY29tcGV0 aXRvcikuDQpGb3IgeWVhcnMgSSB3YXMgdG9sZCB0aGF0IGl0IGlzIHN1cHBvc2VkIHRvIGJlIHVz ZWQgaW4gYWRkaXRpb24gdG8gYW5kIG9uIHRvcCBvZiBUTFMuDQoNCkZhc3QgZm9yd2FyZCBhIGZl dyB5ZWFycyB0aGUgc3RvcnkgaXMgdmVyeSBkaWZmZXJlbnQgbm93Lg0KDQpUaGlzIHR5cGUgb2Yg cG9zaXRpb25pbmcgaGVscHMgeW91IHRvIGF2b2lkIGRlYWxpbmcgd2l0aCBhIG51bWJlciBvZiBm b2xrcyBpbiB0aGUgSUVURiAoaW4gdGhpcyBjYXNlIHdpdGggdGhlIFRMUyBjcm93ZCkgYnV0IGl0 IGRvZXMgbm90IGhlbHAgaW4gdGhlIGxvbmcgcnVuLg0KDQpDaWFvDQpIYW5uZXMNCg0KUFM6IEZX SVcgdGhpcyBpcyBub3QgdGhlIGZpcnN0IHRpbWUgdGhpcyBoYXMgaGFwcGVuZWQuIEFOSU1BIHdh c27igJl0IGFueSBkaWZmZXJlbnQgd2hlbiB0aGUgcHJvcG9uZW50cyBjbGFpbWVkIHRoYXQgSW9U IHdhcyBvdXQgb2Ygc2NvcGUuDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo= --_000_AM6PR08MB36866DB97940341DB43D8331FA240AM6PR08MB3686eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJs YkBpcHYuc3giPnJsYkBpcHYuc3g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBJJ2QgbGlrZSB0byBwdXNoIGJhY2sgb24gdGhpcyBwb2ludC4gSXQg bWF5IGJlIHRoYXQgRURIT0MgaGFzIGJlZW4gYXJvdW5kIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IGEgd2hpbGUgYW5kIGJlZW4gd2VsbC1zb2NpYWxpemVkIHdpdGgg dGhlIElvVCBjcm93ZCwgYnV0IGl0IGlzIGNsZWFybHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBkZWZpY2llbnQgaW4gc2V2ZXJhbCBvdGhlciB0eXBlcyBvZiBtYXR1cml0 eSwgZS5nLiwgcm9idXN0bmVzcyBvZiBmb3JtYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBhbmFseXNlcyBhbmQgc3RhdGUgb2YgaW1wbGVtZW50YXRpb25zIChBRkFJQ1Qp LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gcG9pbnQgb3V0IHRoYXQg aW5pdGlhbGx5IHRoZSB3b3JrIG9uIEVESE9DIHdhcyBpbnRlbnRpb25hbGx5IG5vdCBwb3NpdGlv bmVkIGFzIGEgVExTIHJlcGxhY2VtZW50IChvciBldmVuIGNvbXBldGl0b3IpLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgeWVhcnMgSSB3YXMgdG9sZCB0aGF0IGl0 IGlzIHN1cHBvc2VkIHRvIGJlIHVzZWQgaW4gYWRkaXRpb24gdG8gYW5kIG9uIHRvcCBvZiBUTFMu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFzdCBmb3J3YXJkIGEgZmV3IHllYXJzIHRoZSBz dG9yeSBpcyB2ZXJ5IGRpZmZlcmVudCBub3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg dHlwZSBvZiBwb3NpdGlvbmluZyBoZWxwcyB5b3UgdG8gYXZvaWQgZGVhbGluZyB3aXRoIGEgbnVt YmVyIG9mIGZvbGtzIGluIHRoZSBJRVRGIChpbiB0aGlzIGNhc2Ugd2l0aCB0aGUgVExTIGNyb3dk KSBidXQgaXQgZG9lcyBub3QgaGVscCBpbiB0aGUgbG9uZyBydW4uDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBTOiBGV0lXIHRoaXMgaXMgbm90IHRoZSBmaXJzdCB0 aW1lIHRoaXMgaGFzIGhhcHBlbmVkLiBBTklNQSB3YXNu4oCZdCBhbnkgZGlmZmVyZW50IHdoZW4g dGhlIHByb3BvbmVudHMgY2xhaW1lZCB0aGF0IElvVCB3YXMgb3V0IG9mIHNjb3BlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM6PR08MB36866DB97940341DB43D8331FA240AM6PR08MB3686eurp_-- From nobody Tue Apr 16 02:07:27 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20B120471; Tue, 16 Apr 2019 02:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 jn9VW9mItg0T; Tue, 16 Apr 2019 02:07:24 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FB6120470; Tue, 16 Apr 2019 02:07:23 -0700 (PDT) Received: from [192.168.3.138] (unknown [186.138.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D48C984A05; Tue, 16 Apr 2019 11:07:18 +0200 (CEST) To: IETF SecDispatch From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Cc: secdispatch-chairs@ietf.org Message-ID: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> Date: Tue, 16 Apr 2019 11:07:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 09:07:25 -0000 Folks, At the last secdispatch meeting I presented our I-D draft-gont-predictable-numeric-ids. >From the meeting discussion, it would seem to me that there is support for this work. It would also seem to me that part of this work is to be pursued in an appropriate IRTF rg, while the update to RFC3552 (draft-gont-numeric-ids-sec-considerations) should be pursued as an AD-sponsored document. We're wondering how to proceed here. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 16 06:08:24 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDD912002E for ; Tue, 16 Apr 2019 06:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 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, FROM_EXCESS_BASE64=0.979, 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 1qWmgI22_P54 for ; Tue, 16 Apr 2019 06:08:18 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130083.outbound.protection.outlook.com [40.107.13.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CF6120362 for ; Tue, 16 Apr 2019 06:08:18 -0700 (PDT) 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=dFM7A1Lv0K4iVUVtyjqOzZlL4K0t1P472+PWeR1F0MY=; b=R2Mgcm9H5Em69a76FELqbkRUG0mXEa3FlbIPs5HrUawVh7alJAihCxjy1VsSLUCeo/cl6E1p8246UNZ2MnL9AbsGkdYJfK9TzZHIdQGIgMKRyPIN7LGlLPw5sBOx92jCCfZTf2gGf0Spokj1vc1PoMoRmJhNBuzFzQaVyQoNXyY= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB0955.eurprd07.prod.outlook.com (10.162.27.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Tue, 16 Apr 2019 13:08:12 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1813.003; Tue, 16 Apr 2019 13:08:12 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Rene Struik , "secdispatch@ietf.org" Thread-Topic: brief feedback on draft-selander-lake-reqs-00 Thread-Index: AQHU87p9WntCI6fI+k+wO/iZR8tY5qY+5PSA Date: Tue, 16 Apr 2019 13:08:12 +0000 Message-ID: References: <155507882604.16959.2935532240318784994.idtracker@ietfa.amsl.com> <7a604b70-1c6a-e799-f30c-c9369e62d8d0@gmail.com> In-Reply-To: <7a604b70-1c6a-e799-f30c-c9369e62d8d0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 260b7b7a-61dc-4606-1527-08d6c26c94bd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB0955; x-ms-traffictypediagnostic: HE1PR07MB0955: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(376002)(136003)(396003)(189003)(199004)(71200400001)(11346002)(105586002)(53936002)(316002)(6506007)(58126008)(2616005)(476003)(71190400001)(2501003)(85202003)(82746002)(85182001)(106356001)(486006)(76176011)(68736007)(25786009)(6512007)(966005)(6306002)(14454004)(14444005)(256004)(5660300002)(83716004)(478600001)(325944009)(86362001)(229853002)(99286004)(6436002)(7736002)(8676002)(305945005)(6246003)(53546011)(81166006)(26005)(102836004)(8936002)(81156014)(36756003)(66066001)(66574012)(6486002)(33656002)(3846002)(186003)(2906002)(110136005)(446003)(97736004)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0955; H:HE1PR07MB4172.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-message-info: PNBVn91ZbPaGZGN3Z8c7bmiQNwuMWi+4K9rmHfKIrCVHLm1KUAJN6T97wGBeww5RXbpyekYQLwOdTPtYl8Zc1ecUexwRCZjPAqvxeNeFtSDx6THCQ7lePRFVTO0wjMAXf++msLOs9+9sjDGZGkjziupAW4Apif7EMrYOjdId3Mi/JEKu3FccKUsTGiC5TBWO6iy+aCauKfK3MER3jGL4gDX//JnszLUy8TJnFA33i5beV7TrIXe8wGNzq5//y1OQLOuN+h95nCG2plGEXw/XfBN5a60E9G2DWL0eLW85c7FP8CLby5K0Rp2MUiZ5nYYoGMH/jDJu8dnzL03VCQEEEESIx2EtiNCivOhLhDKkPVa3eHWUDsG4C1P+00ANDer0tIORn2kMam4SLm+CzJl7F1LtAKJv09yr2+PrcMbXWFI= Content-Type: text/plain; charset="utf-8" Content-ID: <9C65F72D12641140BA9C8F0DB0497827@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 260b7b7a-61dc-4606-1527-08d6c26c94bd X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 13:08:12.5238 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB0955 Archived-At: Subject: Re: [Secdispatch] brief feedback on draft-selander-lake-reqs-00 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 13:08:22 -0000 SGkgUmVuZSwNCg0KUGxlYXNlIGZpbmQgcmVzcG9uc2VzIGlubGluZS4gDQoNCu+7v09uIDIwMTkt MDQtMTUsIDIwOjM5LCAiUmVuZSBTdHJ1aWsiIDxyc3RydWlrLmV4dEBnbWFpbC5jb20+IHdyb3Rl Og0KDQogICAgRGVhciBHb3JhbjoNCiAgICANCiAgICBTb21lIGJyaWVmIHJlbWFya3Mgb24gZHJh ZnQtc2VsYW5kZXItbGFrZS1yZXFzOg0KICAgIGEpIGR1dHkgY3ljbGUgKHNlZSBTZWN0aW9uIDQu Mi4xIC0gTG9SYVdhTik6DQogICAgRHV0eSBjeWNsZSBkZXBlbmRzIG9uIGNvbnRleHQgKGUuZy4s IGR1dHkgY3ljbGUgZHVyaW5nIFR4IG9mIGEgc2luZ2xlIA0KICAgIGZyYW1lIGlzIGFsd2F5cyAx MDAlKS4gQWNjb3JkaW5nIHRvIEVUU0kgWzFdLCBTZWN0aW9uIDUuNC4xLCBkdXR5IGN5Y2xlIA0K ICAgIGlzIHJlbGF0aXZlIHRvIG9ic2VydmF0aW9uIHRpbWUgd2luZG93IChUb2JzKSBvZiAxIGhv dXIsIHdoZXJlIA0KICAgIGNvbmZvcm1hbmNlIChbMV0sIFNlY3Rpb24gNS40LjIpLCBpcyBkZWZp bmVkIHJlbGF0aXZlIHRvIG5vcm1hbCB1c2UgDQogICAgZHVyaW5nIG9wZXJhdGlvbmFsIGxpZmV0 aW1lLCB3aGVyZSAidGhlIHJlcHJlc2VudGF0aXZlIHBlcmlvZCBzaGFsbCBiZSANCiAgICB0aGUg bW9zdCBhY3RpdmUgb25lIGluIG5vcm1hbCB1c2Ugb2YgdGhlIGRldmljZS4gQXMgYSBndWlkZSAi Tm9ybWFsIHVzZSIgDQogICAgaXMgY29uc2lkZXJlZCBhcyByZXByZXNlbnRpbmcgdGhlIGJlaGF2 aW91ciBvZiB0aGUgZGV2aWNlIGR1cmluZyANCiAgICB0cmFuc21pc3Npb24gb2YgOTkgJSBvZiB0 cmFuc21pc3Npb25zIGdlbmVyYXRlZCBkdXJpbmcgaXRzIG9wZXJhdGlvbmFsIA0KICAgIGxpZmV0 aW1lIiwgYW5kIHdoZXJlICJQcm9jZWR1cmVzIHN1Y2ggYXMgc2V0dXAsIGNvbW1pc3Npb25pbmcg YW5kIA0KICAgIG1haW50ZW5hbmNlIGFyZSBub3QgY29uc2lkZXJlZCBwYXJ0IG9mIG5vcm1hbCBv cGVyYXRpb24iLiBUaGlzIGRvZXMgDQogICAgc3VnZ2VzdCB0aGF0IGludGVyLWZyYW1lIHNwYWNp bmcgaXMgbm90IG5lY2Vzc2FyaWx5IDk5IGZyYW1lcyBmb3IgZWFjaCANCiAgICBmcmFtZSBzZW50 LCBhcyB0aGlzIHNlY3Rpb24gc2VlbXMgdG8gY2xhaW0uIEluIGZhY3QsIGlmIGtleSBhZ3JlZW1l bnQgaXMgDQogICAgb25seSBkb25lIGFzIHBhcnQgb2YgbmV0d29yayBmb3JtYXRpb24sIGl0IGZh bGxzIG91dHNpZGUgdGhlIGR1dHkgY3ljbGUgDQogICAgcmVndWxhdG9yeSByZXF1aXJlbWVudC4N Cg0KVHdvIGFwcGxpY2F0aW9ucyBvZiBFREhPQyBpbiB0aGUgY29udGV4dCBvZiBMb1JhV0FOIHdl cmUgbWVudGlvbmVkIGF0IHRoZSBpbnRlcmltIG1lZXRpbmcuIE9uZSBpcyBmb3IgdGhlIHJla2V5 aW5nIG9mIExvUmFXQU4gIEFwcEtleSwgdGhlIG90aGVyIGlzIGZvciBlbmQtdG8tZW5kIHNlY3Vy aXR5IG9uIGFwcGxpY2F0aW9uIGxheWVyIGJldHdlZW4gZGV2aWNlIGFuZCBjbG91ZCBzZXJ2aWNl LCB3aGVyZSBMb1JhV0FOIGlzIHRoZSBsYXN0IGhvcC4gSW4gYm90aCBjYXNlcyB0aGUgbWVzc2Fn ZSBzaXplcyBvdmVyIHRoZSBMb1JhV0FOIGxpbmsgYXJlIHJlbGV2YW50IGZvciB0aGUgcGVyZm9y bWFuY2UuIFdoaWxlIHRoZSBmaXJzdCBjYXNlIG1heSBiZSBleGVtcHRlZCwgdGhlIHNlY29uZCBp cyBpbmRlcGVuZGVudCBvZiBuZXR3b3JrIGZvcm1hdGlvbi4gSSB3aWxsIG1ha2UgdGhpcyBtb3Jl IGNsZWFyIGluIC0wMS4NCg0KICAgIGIpIGZldyBtZXNzYWdlcy9mZXcgZnJhbWVzIChTZWN0aW9u IDQuMiAtIERpc2N1c3Npb24pOg0KICAgIFRoZSBzdWdnZXN0aW9uIHRoYXQgYSAzLW1lc3NhZ2Ug cHJvdG9jb2wgaXMgYSByZXF1aXJlbWVudCBzZWVtcyB0byBiZSANCiAgICBtb3JlIGFuIG9waW5p b24vcHJlZmVyZW5jZSBieSB0aGUgYXV0aG9yLCBzaW5jZSBsYWNraW5nIGRldGFpbGVkIA0KICAg IHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uLiB7SWYgc2VuZGluZyBhbiBhZGRpdGlvbmFsIGZyYW1l IGNhdXNlcyAidGhlIA0KICAgIHByb2JhYmlsaXR5IG9mIGVycm9ycyBbdG9dIGluY3JlYXNlIGV4 cG9uZW50aWFsbHkiLCB0aGUgbWVkaXVtIGFjY2VzcyANCiAgICBjb250cm9sIGxheWVyIHNlZW1z IHRvIGJlIHVuZml0IGZvciB1c2UuIE9yLCBkbyB5b3UgbWVhbiB0aGF0IGlmIGVycm9yIA0KICAg IHByb2JhYmlsaXR5IGlzIHAsIG9uZSBnZXRzIHByb2Igbm8gZXJyb3IgaW4gdCBmcmFtZXMgZXF1 YWxzICgxLXApXnQ/IElmIA0KICAgIHNvLCB3aXRoIHNtYWxsIHAgd2l0aCB2aWFibGUgbmV0d29y a3MgYW5kIHNtYWxsIHQsIG9uZSBkZWZpbml0ZWx5IGhhcyANCiAgICAoMS1wKV50IH4gMSAtIHQq cCAoaS5lLiwgYWxtb3N0IGxpbmVhciBkZWdyYWRhdGlvbiByYXRoZXIgdGhhbiB0aGUgbW9yZSAN CiAgICBkcmFtYXRpY2FsbHkgc291bmRpbmcgZXhwb25lbnRpYWwpLn0NCg0KRm9yIE5CLUlvVCwg dGhlIHBlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGljcyBhcmUgbm90IHNlbnNpdGl2ZSB0byB0aGUg ZGlzdHJpYnV0aW9uIG9mIGNvbnRlbnQgaW50byBmcmFtZXMsIGJ1dCB0aGUgdGltZSB1bnRpbCBl bmNyeXB0ZWQgdHJhZmZpYyBkYXRhIGNhbiBiZSBzZW50IGlzIGhpZ2hseSBkZXBlbmRlbnQgb24g dGhlIG51bWJlciBvZiByb3VuZHRyaXBzIGZvciBjb21wbGV0aW5nIHRoZSBwcm90b2NvbC4gVGhl cmVmb3JlIGFzIGZldyByb3VuZHRyaXBzIGFzIHBvc3NpYmxlIGlzIGltcG9ydGFudC4gVGhlIGVy cm9yIHByb2JhYmlsaXR5IGlzIHJlbGF0ZWQgdG8gcHJvcGVydGllcyBvZiBzbG90dGVkIEFsb2hh IHVzZWQgYnkgNlRpU0NILCBidXQgaXMgbm90IGNyaXRpY2FsIGZvciB0aGUgYXJndW1lbnQgc28g aW5zdGVhZCBvZiBnb2luZyBpbnRvIGRldGFpbHMgSSB3aWxsIHJlbW92ZSBpdCBpbiAtMDEuDQoN CiAgICBjKSBjb25mbGljdGluZyByZXF1aXJlbWVudHMgKFNlY3Rpb24gNC4xIC0gQUtFIGZvciBP U0NPUkUgdnMuIFNlY3Rpb24gDQogICAgNC4yIC0gTGlnaHR3ZWlnaHQpOg0KICAgIFRoZXJlIGFy ZSB0cmFkZS1vZmZzIGJldHdlZW4gY29tbXVuaWNhdGlvbiBvdmVyaGVhZCBhbmQgc2VjdXJpdHkg DQogICAgcHJvcGVydGllcywgd2hpY2ggZ2VuZXJhbGx5IHNob3VsZCBiZSBleHBsb3JlZCBpbiBt b3JlIGRldGFpbCBiZWZvcmUgDQogICAgaW1wb3NpbmcgYSByZXF1aXJlbWVudC4gQXMgYW4gZXhh bXBsZSwgYSBzdHJpY3QgcmVxdWlyZW1lbnQgZm9yIFBGUyBtYXkgDQogICAgbmVjZXNzaXRhdGUg aW5jcmVhc2VkIGNvbW11bmljYXRpb24gb3ZlcmhlYWQsIHNpbmNlLCBlLmcuLCBhIA0KICAgIGNv bW11bmljYXRpb24gZmFpbHVyZSBkdXJpbmcgYW4gQUtDLXNjaGVtZSB3aXRoIHN0cmljdCBQRlMg bWF5IHByZWNsdWRlIA0KICAgIHJldXNpbmcgdGhpcyBrZXlpbmcgbWF0ZXJpYWwgd2l0aCBhIHJl dHJ5IG1lY2hhbmlzbS4NCg0KSSBkaWRuJ3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhpcyBjb21tZW50 LCBpbiBwYXJ0aWN1bGFyIHRoZSBsYXN0IHNlbnRlbmNlLiBPU0NPUkUgaXMgbm90IHJlcXVpcmVk IHRvIGJlIGRlcGxveWVkIHdpdGggUEZTLCBidXQgdGhlcmUgYXJlIGFwcGxpY2F0aW9ucyB3ZXJl IFBGUyBpcyBuZWVkZWQgYW5kIHRoZSBpbmNyZWFzZWQgY29tbXVuaWNhdGlvbiBvdmVyaGVhZCBv ZiBhbiBBS0UgaXMgYWNjZXB0YWJsZS4NCg0KICAgIGQpIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IChTZWN0aW9uIDYpOg0KICAgIENvbnRyYXJ5IHRvIHdoYXQgaXMgc3VnZ2VzdGVkLCB0aGUgZG9j dW1lbnQgaXMgbW9zdGx5IGFib3V0ICJzaXplIiANCiAgICBhcmd1bWVudHMgYW5kIGRvZXMgbm90 IG9mZmVyIGEgZGVmaW5pdGlvbiBvZiBkZXNpcmVkIGFsZ29yaXRobWljIGFuZCANCiAgICBvcGVy YXRpb25hbCBzZWN1cml0eSBwcm9wZXJ0aWVzIGZvciBzZW5zb3IgbmV0d29ya3MuDQoNCkkgd2ls bCByZWZvcm11bGF0ZSB0aGUgc2VudGVuY2Ugb2YgdGhpcyBzZWN0aW9uIGluIC0wMS4NCg0KICAg IGUpIHByb3RvY29sIGZsYXZvcnMgKFNlY3Rpb24gMik6DQogICAgVGhlIHN1Z2dlc3RlZCBwcm90 b2NvbCBvcHRpb25zIGluY2x1ZGUgYXV0aGVudGljYXRlZCBrZXkgYWdyZWVtZW50IHVzaW5nIA0K ICAgIHN5bW1ldHJpYy1rZXksIHJhdyBwdWJsaWMga2V5cywgYW5kIGNlcnRpZmllZCBwdWJsaWMg a2V5cy4gQW5vdGhlciANCiAgICBvcHRpb24sIHdoaWNoIG1heSBiZSB3b3J0aCBleHBsb3Jpbmcg KGV2ZW4gaWYgZGlzY2FyZGVkIGJhc2VkIG9uIHNvdW5kIA0KICAgIHJhdGlvbmFsZSkgaXMgYSBr ZXkgYWdyZWVtZW50IHNjaGVtZSB3aGVyZSBhdXRoZW50aWNhdGlvbiBpcyBiYXNlZCBvbiBhIA0K ICAgIHNob3J0IHNlY3JldCBhdXRoZW50aWNhdGlvbiBzdHJpbmcgKHBhc3N3b3JkKSBvciBhIHNo b3J0IHB1YmxpYyANCiAgICBhdXRoZW50aWMsIHlldCBub3Qgc2VjcmV0IHN0cmluZyB0aGF0IGlz IHByb3ZpZGVkIGJ5IGEgdXNlciAoc2VlLCBlLmcuLCANCiAgICBbM10pLg0KDQpPdGhlciBjcmVk ZW50aWFscyBtYXkgYmUgYWRkZWQgbGF0ZXIgaW4gdGhlIHByb2Nlc3MsIHRoZSBvbmVzIGN1cnJl bnRseSBsaXN0ZWQgYXJlIGJlbGlldmVkIHRvIGJlIHRoZSBtb3N0IHJlbGV2YW50Lg0KDQogICAg ZikgQ09TRSBhbGdvcml0aG1zIChTZWN0aW9uIDQuMSk6DQogICAgVGhlIGFsZ29yaXRobXMgaW4g dGhlIGN1cnJlbnQgQ09TRSBzcGVjaWZpY2F0aW9uIChSRkMgODE1MikgbWF5IG5vdCBoYXZlIA0K ICAgIGEgcmljaCBlbm91Z2ggc2V0IG9mIHByaW1pdGl2ZXMgdG8gaW5zdGFudGlhdGUgdGhlIHNv dWdodCBhZnRlciANCiAgICBhdXRoZW50aWNhdGVkIGtleSBhZ3JlZW1lbnQgcHJvdG9jb2wuIEFz IGFuIGV4YW1wbGUsIHRvIG15IA0KICAgIHVuZGVyc3RhbmRpbmcsIENPU0Ugb25seSBmYWNpbGl0 YXRlcyB1c2Ugb2Ygc3RhdGljLWVwaGVtZXJhbCBjby1mYWN0b3IgDQogICAgRGlmZmllLUhlbGxt YW4uIFRodXMsIHNvbWUgY2hhbmdlcyB0byB0aGUgQ09TRSBzcGVjaWZpY2F0aW9uIG1heSBiZSAN CiAgICByZXF1aXJlZCBpZiBvbmUgd2lzaGVzIHRvIHVzZSBhIHByb3RvY29sIHRoYXQgdXNlcyBj by1mYWN0b3IgDQogICAgRGlmZmllLUhlbGxtYW4gYmFzZWQgb24gZXBoZW1lcmFsIGtleSBzaGFy ZXMuIChPZiBjb3Vyc2UsIHRoaXMgbWF5IGJlIA0KICAgIGVhc2lseSBmYWNpbGl0YXRlZCwgZXNw LiBpZiB0aGUgdW5kZXJseWluZyBjb3JlIGNyeXB0byBwcmltaXRpdmUgaXMgDQogICAgYWxyZWFk eSBkZWZpbmVkKS4NCg0KRnJvbSBhIENPU0UgcG9pbnQgdGhlIEVESE9DIHVzZSBvZiBESCBpcyBT dGF0aWMtU3RhdGljLCBidXQsIGFzIHlvdSByZW1hcmssIHRoaXMgY2FuIGVhc2lseSBiZSBhZGRl ZCB0byBDT1NFIHNob3VsZCB0aGF0IGFzc3VtcHRpb24gY2hhbmdlLiANCg0KICAgIFRoZXNlIGNv bW1lbnRzIGlsbHVzdHJhdGUgdGhhdCBzb21lIHJlcXVpcmVtZW50cyBhcmUgbGVzcyBjbGVhci1j dXQgdGhhbiANCiAgICBhcyBzdWdnZXN0ZWQgaW4gZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzLTAw IGFuZCwgdGhhdCwgaW4gZmFjdCwgdGhlcmUgDQogICAgbWF5IGJlIG1vcmUgdG8gdGhpcyB0aGFu IGp1c3QgYSAic21hbGxlciBpcyBhbHdheXMgYmV0dGVyIiBhcmd1bWVudC4NCg0KVGhlIGludGVu dCB3aXRoIHRoaXMgZHJhZnQgd2FzIG5vdCB0byB3cml0ZSBhIHZlcnkgZGV0YWlsZWQgcmVxdWly ZW1lbnRzIHNwZWNpZmljYXRpb24gdGhhdCBvbmUgZGF5IHdpbGwgYmVjb21lIGFuIFJGQy4gSXRz IHB1cnBvc2Ugd2FzIHRvIG1lZXQgYSByZXF1ZXN0IHRvIGNvbXBpbGUgZGlzY3Vzc2lvbiBzcHJl YWQgb3V0IG92ZXIgZGlmZmVyZW50IGVtYWlscywgaW5jbHVkaW5nIHNvbWUgZ2VuZXJhbCBtZXRy aWNzIHdoaWNoIGFyZSBleHBlY3RlZCB0byBoYXZlIGEgcG9zaXRpdmUgaW1wYWN0IG9uIHRoZSBw ZXJmb3JtYW5jZSBpbiBjb21tb24gc2V0dGluZ3MuIA0KDQpHw7ZyYW4NCg0KDQogICAgUmVuZQ0K ICAgIA0KICAgIFJlZjoNCiAgICBbMV0gRVRTSSBFTiAzMDAgMjIwLTEgVjMuMS4xICgyMDE3LTAy KTsNCiAgICBbMl0gRVRTSSBFTiAzMDAgMjIwLTIgVjMuMS4xICgyMDE3LTAyKTsNCiAgICBbM10g QXV0aGVudGljYXRlZCBLZXkgQWdyZWVtZW50IC0gVXNpbmcgU2hvcnQgQXV0aGVudGljYXRlZCBT dHJpbmdzIA0KICAgIChTZXJnZSBWYXVkZW5heSwgQ3J5cHRvIDIwMDUpDQogICAgDQogICAgT24g NC8xMi8yMDE5IDEyOjIwIFBNLCBHw7ZyYW4gU2VsYW5kZXIgd3JvdGU6DQogICAgPiBPbiByZXF1 ZXN0IEkgY29tcGlsZWQgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIGxpZ2h0d2VpZ2h0IEFLRSBm b3IgT1NDT1JFIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCBpbnRvIGEgZHJhZnQuIFRoaXMgaXMgbm90 IGV4YWN0bHkgdGhlIGZvcm11bGF0aW9uIGJ5IHRoZSBzZWN1cml0eSBBRHMgYnV0IHRoZSBtYWlu IHJlcXVpcmVtZW50cyBzaG91bGQgYmUgdGhlcmUuDQogICAgPg0KICAgID4gR8O2cmFuDQogICAg Pg0KICAgID4gT24gMjAxOS0wNC0xMiwgMTY6MjAsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4NCiAgICA+ICAgICAgDQog ICAgPiAgICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zZWxhbmRlci1sYWtlLXJlcXMt MDAudHh0DQogICAgPiAgICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR8O2 cmFuIFNlbGFuZGVyIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgPiAgICAgIElFVEYgcmVwb3NpdG9y eS4NCiAgICA+ICAgICAgDQogICAgPiAgICAgIE5hbWU6CQlkcmFmdC1zZWxhbmRlci1sYWtlLXJl cXMNCiAgICA+ICAgICAgUmV2aXNpb246CTAwDQogICAgPiAgICAgIFRpdGxlOgkJUmVxdWlyZW1l bnRzIGZvciBhIExpZ2h0d2VpZ2h0IEFLRSBmb3IgT1NDT1JFLg0KICAgID4gICAgICBEb2N1bWVu dCBkYXRlOgkyMDE5LTA0LTEyDQogICAgPiAgICAgIEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQogICAgPiAgICAgIFBhZ2VzOgkJNw0KICAgID4gICAgICBVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlbGFuZGVyLWxha2UtcmVx cy0wMC50eHQNCiAgICA+ICAgICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXNlbGFuZGVyLWxha2UtcmVxcy8NCiAgICA+ICAgICAgSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1sYWtl LXJlcXMtMDANCiAgICA+ICAgICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzDQogICAgPiAgICAgIA0K ICAgID4gICAgICANCiAgICA+ICAgICAgQWJzdHJhY3Q6DQogICAgPiAgICAgICAgIFRoaXMgZG9j dW1lbnQgY29udGFpbnMgdGhlIHJlcXVpcmVtZW50cyBmb3IgYSBsaWdodHdlaWdodA0KICAgID4g ICAgICAgICBhdXRoZW50aWNhdGVkIGtleSBleGNoYW5nZSBwcm90b2NvbCBmb3IgT1NDT1JFLg0K ICAgID4gICAgICANCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgID4g ICAgICANCiAgICA+ICAgICAgDQogICAgPiAgICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICA+ ICAgICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCiAgICA+ICAgICAgDQogICAgPiAgICAgIFRoZSBJRVRGIFNlY3Jl dGFyaWF0DQogICAgPiAgICAgIA0KICAgID4gICAgICANCiAgICA+DQogICAgPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gU2VjZGlzcGF0Y2gg bWFpbGluZyBsaXN0DQogICAgPiBTZWNkaXNwYXRjaEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KICAgIA0KICAgIA0KICAg IC0tIA0KICAgIGVtYWlsOiByc3RydWlrLmV4dEBnbWFpbC5jb20gfCBTa3lwZTogcnN0cnVpaw0K ICAgIGNlbGw6ICsxICg2NDcpIDg2Ny01NjU4IHwgVVM6ICsxICg0MTUpIDY5MC03MzYzDQogICAg DQogICAgDQoNCg== From nobody Thu Apr 18 00:39:23 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2581200DE for ; Thu, 18 Apr 2019 00:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 l6bgtA-0WfTk for ; Thu, 18 Apr 2019 00:39:18 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150050.outbound.protection.outlook.com [40.107.15.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1C6120048 for ; Thu, 18 Apr 2019 00:39:18 -0700 (PDT) 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=BdEtmJ+BWT7AExvD6lHs1fTGVvDzhjZNG6wd+s8o/0k=; b=aHUGb+iM0IQhQTC8bSj/TjO5ezPbUh2VgfsgczflctXvzzYeuFKQVqZcRMIhVL8z5xxCu9KLEKsrU9p42BpPkdxaAvLaD1ae/DuKTGZuEtl3Sg8jjI3Y6F2Fl5cP2lBWXHpZfKTIEBlz+KpMazbH5Cdj2F+saKAytVXLG7sE+ZQ= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4396.eurprd07.prod.outlook.com (20.176.167.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 07:39:15 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 07:39:15 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "secdispatch@ietf.org" Thread-Topic: New Version Notification for draft-selander-lake-reqs-01.txt Thread-Index: AQHU9OfcmRiuCoiovU+rTC+mEFa336ZBq1sA Date: Thu, 18 Apr 2019 07:39:15 +0000 Message-ID: <374BA2E2-4833-4626-A59C-EE000E4E6926@ericsson.com> References: <155548294335.24918.6612734423233083191.idtracker@ietfa.amsl.com> In-Reply-To: <155548294335.24918.6612734423233083191.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d05f01c9-dbc0-404b-c8e5-08d6c3d0f516 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4396; x-ms-traffictypediagnostic: HE1PR07MB4396: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(39860400002)(376002)(366004)(199004)(189003)(76176011)(11346002)(446003)(486006)(2616005)(476003)(6116002)(6506007)(86362001)(3846002)(26005)(102836004)(2501003)(186003)(966005)(36756003)(2351001)(71200400001)(71190400001)(83716004)(14454004)(478600001)(2906002)(25786009)(66574012)(85202003)(5640700003)(81156014)(6436002)(82746002)(8676002)(81166006)(85182001)(8936002)(33656002)(316002)(58126008)(14444005)(66066001)(53936002)(15650500001)(6486002)(7736002)(1730700003)(5660300002)(305945005)(68736007)(229853002)(6916009)(2473003)(6512007)(6306002)(256004)(99286004)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4396; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5Bkf9MxYCJpyiUrT++sPa32WhSgJh/Sc31WIVgAwXL7A9r82Fyt2aK28bHfcJzv1nyap8Uf0aawmyD33dtSPzjwSwGbY4+2NhmJUOfK2hWd2S5BMQX+uzJc8dsVaJe6g9BsyGXI9/94NFPsDGUir3eY6qPqgRrpJd4hoQscDYu7UYEZAOtTJ7uLZuQcqouwZthUQtySLP3W4y9tekoMCLccaJQ+4KE2XpctU5/5tGv7uinNEYx3uNgE43pJYu1ywimAStMX8Zf3n3DlDbH58fWRetsizTtRWTDK7nNmRVQEBHj++8Rmyj9G88Cc7k9phqQnRSgBqnJbBKbZdqTwS+XRLK1EHZ1/dw2M8WkRay9Dk13uqzkESkJyLUe+tRd6CI6grucpaAfxJJfLULPJPXKI4XLum+Yv871OOiVmzTug= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d05f01c9-dbc0-404b-c8e5-08d6c3d0f516 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 07:39:15.0778 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4396 Archived-At: Subject: [Secdispatch] FW: New Version Notification for draft-selander-lake-reqs-01.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 07:39:21 -0000 VXBkYXRlIGJhc2VkIG9uIHRoZSBzZWN1cml0eSBBRHMnIHN1bW1hcnkgbWFpbCBhbmQgY29tbWVu dHMgZnJvbSBSZW5lLiANCg0KR8O2cmFuDQoNCg0K77u/T24gMjAxOS0wNC0xNywgMDg6MzYsICJp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3Rl Og0KDQogICAgDQogICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNlbGFuZGVyLWxha2Ut cmVxcy0wMS50eHQNCiAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEfDtnJh biBTZWxhbmRlciBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3NpdG9yeS4NCiAgICAN CiAgICBOYW1lOgkJZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzDQogICAgUmV2aXNpb246CTAxDQog ICAgVGl0bGU6CQlSZXF1aXJlbWVudHMgZm9yIGEgTGlnaHR3ZWlnaHQgQUtFIGZvciBPU0NPUkUu DQogICAgRG9jdW1lbnQgZGF0ZToJMjAxOS0wNC0xNw0KICAgIEdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQogICAgUGFnZXM6CQk4DQogICAgVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zZWxhbmRlci1sYWtlLXJlcXMtMDEudHh0 DQogICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXNlbGFuZGVyLWxha2UtcmVxcy8NCiAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWxha2UtcmVxcy0wMQ0KICAgIEh0bWxpemVk OiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNlbGFu ZGVyLWxha2UtcmVxcw0KICAgIERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzLTAxDQogICAgDQogICAgQWJzdHJh Y3Q6DQogICAgICAgVGhpcyBkb2N1bWVudCBjb21waWxlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciBh IGxpZ2h0d2VpZ2h0DQogICAgICAgYXV0aGVudGljYXRlZCBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wg Zm9yIE9TQ09SRS4NCiAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgDQog ICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAg VGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICANCiAgICANCg0K From nobody Thu Apr 18 00:47:25 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE9120094 for ; Thu, 18 Apr 2019 00:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 I-x9TmQlKhbB for ; Thu, 18 Apr 2019 00:47:22 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80042.outbound.protection.outlook.com [40.107.8.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3511120048 for ; Thu, 18 Apr 2019 00:47:21 -0700 (PDT) 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=gIfdFR/+RKMwYyGTXwrWKYjKGxYnzUNOaTzW2CqmjDc=; b=Y0uEsC0ONHCKXi86NwyWAR3he5/FdarqpCPL1ctMXvRL6F+OWS1j8J5a6JDm8/1XUVJ7plnADNS1SEpCyPiVzfp3JlU25wazeiOYyvVZQ/r7z85QICGk912pS6cNLgSGT0yWdC4w9LL/Zxkc3WMo036Vxps7CYzkKM3bs2Cl7xg= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1SPR01MB13.eurprd07.prod.outlook.com (10.170.251.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.10; Thu, 18 Apr 2019 07:47:18 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 07:47:18 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muA== Date: Thu, 18 Apr 2019 07:47:18 +0000 Message-ID: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1332b7bd-193a-4d20-4b5c-08d6c3d21567 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1SPR01MB13; x-ms-traffictypediagnostic: HE1SPR01MB13: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(396003)(346002)(39860400002)(199004)(189003)(40434004)(8936002)(2616005)(110136005)(54906003)(6436002)(6246003)(71200400001)(71190400001)(486006)(58126008)(83716004)(86362001)(316002)(66574012)(102836004)(6116002)(476003)(85202003)(26005)(3846002)(6506007)(25786009)(478600001)(53936002)(81166006)(81156014)(8676002)(6512007)(97736004)(4326008)(66066001)(2906002)(14454004)(36756003)(186003)(82746002)(5660300002)(68736007)(5024004)(85182001)(99286004)(7736002)(305945005)(14444005)(256004)(33656002)(229853002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR01MB13; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xZaZ845f5LjCg2l+6FgUQUseiJl8yxm77qf6XvGzi3AsVlb+arX0C1i2XRpqO4z501IR3nZLWx4s57ThYhUwVePEiun9ygv2D4QHqheZoOqGXqmo3WaTlzAf3gjPd4Grh20L7qcqDviK9jKSq0BNyDCIizhkO3J5/7aNjCVNjCdQ70sgNNlx9Fgl86j70yKVxy2L7sXuKrNf1LVymV3UtEtWVZeDdTLluxXAhqeaKo+nQ5CzR3gbAKYinE+VK9RKk8c/4PHgOQBNTta5Bz5jNFIe8G9Yl0g+Ty+5nlQGVsi4WN5yVCgPFPcI1DId2XheThn+38U33K7i7DhHSy6btEF8aDVBFfIqTepZ0LWqKDQXC8qunb6Fh8Rme5PAqln/0zKQk5909a8IBRSzE4Z7iRUtn4fhRj/PRHBSlJDX6f0= Content-Type: text/plain; charset="utf-8" Content-ID: <2DCF198F7E51BD40BAE916DCE5211F73@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1332b7bd-193a-4d20-4b5c-08d6c3d21567 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 07:47:18.7772 (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-Transport-CrossTenantHeadersStamped: HE1SPR01MB13 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 07:47:24 -0000 SGkgSGFubmVzLCANCg0K77u/T24gMjAxOS0wNC0xNiwgMDk6MjYsICJTZWNkaXNwYXRjaCBvbiBi ZWhhbGYgb2YgSGFubmVzIFRzY2hvZmVuaWciIDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCg0KICAgID4g ICAgIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PiB3cm90ZToNCiAgICA+ICAgICAgICAgPiBJ J2QgbGlrZSB0byBwdXNoIGJhY2sgb24gdGhpcyBwb2ludC4gSXQgbWF5IGJlIHRoYXQgRURIT0Mg aGFzIGJlZW4gYXJvdW5kIGZvcg0KICAgID4gICAgICAgICA+IGEgd2hpbGUgYW5kIGJlZW4gd2Vs bC1zb2NpYWxpemVkIHdpdGggdGhlIElvVCBjcm93ZCwgYnV0IGl0IGlzIGNsZWFybHkNCiAgICA+ ICAgICAgICAgPiBkZWZpY2llbnQgaW4gc2V2ZXJhbCBvdGhlciB0eXBlcyBvZiBtYXR1cml0eSwg ZS5nLiwgcm9idXN0bmVzcyBvZiBmb3JtYWwNCiAgICA+ICAgICAgICAgPiBhbmFseXNlcyBhbmQg c3RhdGUgb2YgaW1wbGVtZW50YXRpb25zIChBRkFJQ1QpLg0KICAgICANCiAgICBJIHdvdWxkIGxp a2UgdG8gcG9pbnQgb3V0IHRoYXQgaW5pdGlhbGx5IHRoZSB3b3JrIG9uIEVESE9DIHdhcyBpbnRl bnRpb25hbGx5IG5vdCBwb3NpdGlvbmVkIGFzIGEgVExTIHJlcGxhY2VtZW50IChvciBldmVuIGNv bXBldGl0b3IpLiBGb3IgeWVhcnMgSSB3YXMgdG9sZCB0aGF0IGl0IGlzIHN1cHBvc2VkIHRvIGJl IHVzZWQgaW4gYWRkaXRpb24gdG8gYW5kIG9uIHRvcCBvZiBUTFMuIEZhc3QgZm9yd2FyZCBhIGZl dyB5ZWFycyB0aGUgc3RvcnkgaXMgdmVyeSBkaWZmZXJlbnQgbm93LiANCg0KW0dTXSBUaGUgQUtF IGZvciBPU0NPUkUgY2xlYXJseSBtdXN0IHN1cHBvcnQgdGhlIHNhbWUgdHJhbnNwb3J0IGFzIE9T Q09SRS4gRnJvbSBmaXJzdCBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdG8gdGhlIGFwcHJvdmVkIHZl cnNpb24gb2YgT1NDT1JFLCB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gc3RhdGVzIHRoYXQgT1ND T1JFIG1heSBvciBtYXkgbm90IGJlIHVzZWQgb3ZlciBUTFMvRFRMUy4gKFRoZSBhcHByb3ZlZCB2 ZXJzaW9uIHJlY29tbWVuZHMgdGhlIHVzZSBvZiBhZGRpdGlvbmFsIFRMUyBmb3IgY2VydGFpbiBo b3BzLCBidXQgbm90IG92ZXIgY29uc3RyYWluZWQgbmV0d29ya3MuKSBPU0NPUkUvQUtFIG92ZXIg VExTIGlzIHNpbWlsYXIgdG8gVExTIG92ZXIgSVBzZWMvSUtFdjIuDQoNCkfDtnJhbg0KDQoNClRo aXMgdHlwZSBvZiBwb3NpdGlvbmluZyBoZWxwcyB5b3UgdG8gYXZvaWQgZGVhbGluZyB3aXRoIGEg bnVtYmVyIG9mIGZvbGtzIGluIHRoZSBJRVRGIChpbiB0aGlzIGNhc2Ugd2l0aCB0aGUgVExTIGNy b3dkKSBidXQgaXQgZG9lcyBub3QgaGVscCBpbiB0aGUgbG9uZyBydW4uDQogICAgIA0KICAgIENp YW8NCiAgICBIYW5uZXMNCiAgICAgDQogICAgUFM6IEZXSVcgdGhpcyBpcyBub3QgdGhlIGZpcnN0 IHRpbWUgdGhpcyBoYXMgaGFwcGVuZWQuIEFOSU1BIHdhc27igJl0IGFueSBkaWZmZXJlbnQgd2hl biB0aGUgcHJvcG9uZW50cyBjbGFpbWVkIHRoYXQgSW9UIHdhcyBvdXQgb2Ygc2NvcGUuDQogICAg DQogICAgDQogICAgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiAgICAgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K ICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 18 04:01:01 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE3120144 for ; Thu, 18 Apr 2019 04:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 bY9oDxy3kL-P for ; Thu, 18 Apr 2019 04:00:57 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80045.outbound.protection.outlook.com [40.107.8.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5E912009C for ; Thu, 18 Apr 2019 04:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jAkwZZBuQ2gL01BOkQ9XjvL6D8Rb+hR+pkvb1fxhK6Q=; b=RakxqHQo5UV4StbbWZvAEOuAQoiien+4BpfhgaDd8Qc4yQqEUWwFqn4dH0u8jCRIRIIiKR8RBTuQ8cf0iOYn1/Gs6euZ9e4VqfQRdGzrCBvQOo5DZGPzobWJ0yiqeVTtjK1aNlqR2+IEKIlE6j8n0XG4VBakstnVMIVT5wWbhCQ= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4405.eurprd08.prod.outlook.com (20.179.7.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 11:00:53 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 11:00:53 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQ Date: Thu, 18 Apr 2019 11:00:53 +0000 Message-ID: References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> In-Reply-To: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa39e513-1e77-4f15-cdd4-08d6c3ed2031 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB4405; x-ms-traffictypediagnostic: AM6PR08MB4405: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(136003)(396003)(366004)(40434004)(189003)(199004)(99286004)(3846002)(74316002)(4744005)(6116002)(53936002)(97736004)(229853002)(66066001)(446003)(71190400001)(33656002)(102836004)(54906003)(256004)(186003)(68736007)(14444005)(14454004)(2906002)(11346002)(7696005)(6436002)(5660300002)(71200400001)(486006)(110136005)(305945005)(55016002)(476003)(9686003)(25786009)(7736002)(5024004)(72206003)(6246003)(4326008)(26005)(81156014)(86362001)(6506007)(52536014)(316002)(76176011)(81166006)(478600001)(8676002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4405; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HOJAVoSDlL9E1nKALdY8cOxapAllKNelTq+HpfDJa7rJbC+lZ8wN5kcHs8yIJxa/eWCJ9yCfMHazf1XB8JrOXNBydGbfdWEPr9dB0uBYT/fWm2r3EuLvO9c2kaeXhp5r2WriewWzeDiVWtkU2efkAFNg7zY0TsVwwL/4yEcG1K0NueJbybhZpBdqWn6HQcuwtL4J6B4yorm1ksxnpXzamMC0KY/dx2YHy/AgM1kb0NgRkv2tHNoNFiidhF0BAb3KGDKuJaKkL370IcvWx6LxeGzekOrwHS6Usmu39boIuIUQvktC9r5Zdyzm55yB+yozjbcC4VakpOdpgQnyv8ePgI85ZRSWjOdA8Z99pVrGq3BpMlQlq+s4SJRxSTNGPbOSbBT4LiA4lxipeTU8TEpxGWrCWCau0+K3c0cRcqanlo8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa39e513-1e77-4f15-cdd4-08d6c3ed2031 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 11:00:53.3643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4405 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 11:01:00 -0000 SGkgR29lcmFuLA0KDQogW0dTXSBUaGUgQUtFIGZvciBPU0NPUkUgY2xlYXJseSBtdXN0IHN1cHBv cnQgdGhlIHNhbWUgdHJhbnNwb3J0IGFzIE9TQ09SRS4NCg0KTm8sIGl0IGRvZXNuJ3QuDQoNCj4g RnJvbSBmaXJzdCBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdG8gdGhlIGFwcHJvdmVkIHZlcnNpb24g b2YgT1NDT1JFLCB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gc3RhdGVzIHRoYXQgT1NDT1JFIG1h eSBvciBtYXkgbm90IGJlIHVzZWQgb3ZlciBUTFMvRFRMUy4NCj4gKFRoZSBhcHByb3ZlZCB2ZXJz aW9uIHJlY29tbWVuZHMgdGhlIHVzZSBvZiBhZGRpdGlvbmFsIFRMUyBmb3IgY2VydGFpbiBob3Bz LCBidXQgbm90IG92ZXIgY29uc3RyYWluZWQgbmV0d29ya3MuKQ0KWW91IHNlZSB3aGF0IEkgYW0g dGFsa2luZyBhYm91dC4uLg0KDQo+IE9TQ09SRS9BS0Ugb3ZlciBUTFMgaXMgc2ltaWxhciB0byBU TFMgb3ZlciBJUHNlYy9JS0V2Mi4NCllvdSBrbm93IHRoYXQgbm9ib2R5IHVzZXMgSVBzZWMgLyBJ S0V2MiBpbiBhbiBJb1QgY29udGV4dCAoZXZlbiB0aG91Z2ggc29tZSBvZiB5b3VyIGNvLXdvcmtl cnMgZXZlbiBhcmd1ZWQgZm9yIGl0IHNvbWUgdGltZSBhZ28pLg0KDQpDaWFvDQpIYW5uZXMNCg0K DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Apr 18 04:04:08 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9441200EA for ; Thu, 18 Apr 2019 04:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 cSIaHI9owk7I for ; Thu, 18 Apr 2019 04:04:04 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140087.outbound.protection.outlook.com [40.107.14.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185F612009C for ; Thu, 18 Apr 2019 04:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AUSgVmsH0hgbpowR83HrziZSGbUH161Y1r4I6rVeOVg=; b=LASeZTG3VkjtR2VA47sQHxNhqjIXTN9BgcqbnHNHKbjZdZWWQ2wU4sxknu/+/NjMEtTxsubqxyMsm/DmKY7Glt6RYQhRauVzyMnQJPj8yydiQ2BMeVqYDa42CxcUbMMEpQt2d7Smb+IfPKOkqWRYAd08FaoTIsdP9YX5cQGg/cU= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4533.eurprd08.prod.outlook.com (20.179.18.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 11:04:01 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 11:04:01 +0000 From: Hannes Tschofenig To: "secdispatch@ietf.org" Thread-Topic: draft-selander-lake-reqs-00: SDOs Thread-Index: AdT1JpDclWNnzcQJTPaQeISID8R4nA== Date: Thu, 18 Apr 2019 11:04:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: babcbc89-709f-49e6-59ff-08d6c3ed9076 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB4533; x-ms-traffictypediagnostic: AM6PR08MB4533: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(136003)(376002)(366004)(39860400002)(396003)(40434004)(189003)(199004)(99286004)(25786009)(5660300002)(186003)(790700001)(3846002)(6116002)(66066001)(14454004)(68736007)(54896002)(7736002)(72206003)(486006)(71190400001)(53936002)(86362001)(478600001)(55016002)(6306002)(71200400001)(9686003)(74316002)(8936002)(33656002)(4744005)(5640700003)(81166006)(6916009)(2501003)(476003)(6436002)(97736004)(236005)(8676002)(7696005)(2351001)(81156014)(1730700003)(52536014)(606006)(14444005)(5024004)(6506007)(9326002)(26005)(316002)(2906002)(256004)(102836004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4533; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HTjJRibUCjrBLWoKrSrkaiXOKwCOaCb33E6gTzggPFC/LlBcO3waegmIJISI6Z/0S9ai9ZAI2J/3MjNVt6flicFFe81LRz0oJVDlq5Secz08pFQjvo/xG2aq2MHq9OuhiNBWiuxHOXJV3wKnC+yBfH0fw0ZFTC8c4Mxh9e70uTgLHkZA3tlkSpWZYMJxy+WdxZzGwm83g9BaDgyLKASqr+/dmSUBQ3yW41zUBvSFv5rQRZ0l571/XSqMGB8a6IGUNcemhGp+EVX3A8+1Aiy5RQiigJSURlYqRbI4Hjb0/SqmgiKFf4DCxBcUuS2X2tYH44XE7rMbx9HyNGLOWIrwCe9wmPMzec/j5iP8JY5H2yHhsfVM3N3hL3K4RHo3djFP8fWcdYaAi793QFDioALXgrFOqFy2ohk/HNywJnGeKCw= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3686B5416E3C5770708ADAD6FA260AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: babcbc89-709f-49e6-59ff-08d6c3ed9076 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 11:04:01.6543 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4533 Archived-At: Subject: [Secdispatch] draft-selander-lake-reqs-00: SDOs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 11:04:07 -0000 --_000_AM6PR08MB3686B5416E3C5770708ADAD6FA260AM6PR08MB3686eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Goeran, I am not a big fan of motivating work by referencing to other SDOs. Why? Because it is largely a forum shopping activity. Others on the list ma= y not know that you brought OSCORE to the OMA / LwM2M v1.1 specification. It is an optional feature. You wrote that part of the specification, if I r= ecall correctly. o LwM2M version 1.1 [LwM2M]. LwM2M v1.1 defines bindings to two challenging radio technologies where OSCORE will be deployed: LoRaWAN and NB-IoT. Regarding "... where OSCORE will be deployed": Just because you add an opti= onal feature to a specification does not get it deployed. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB3686B5416E3C5770708ADAD6FA260AM6PR08MB3686eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Goeran,

 

I am not a big fan of motivating work by referencing= to other SDOs.

 

Why? Because it is largely a forum shopping activity= . Others on the list may not know that you brought OSCORE to the OMA / LwM2= M v1.1 specification.

It is an optional feature. You wrote that part of th= e specification, if I recall correctly.

 

   o  LwM2M version 1.1 [LwM2M].  LwM2M v1.1 def=
ines bindings to two
      challenging=
 radio technologies where OSCORE will be deployed:
      LoRaWAN and=
 NB-IoT.  

 

Regarding “… where OSCORE will be deployed”: Just because you add an optional fea= ture to a specification does not get it deployed.

 =

Ciao

Hannes=

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB3686B5416E3C5770708ADAD6FA260AM6PR08MB3686eurp_-- From nobody Thu Apr 18 04:59:38 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D074120052 for ; Thu, 18 Apr 2019 04:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 uGUgYKraOo7P for ; Thu, 18 Apr 2019 04:59:34 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30059.outbound.protection.outlook.com [40.107.3.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CB71200A0 for ; Thu, 18 Apr 2019 04:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CBeQz9dIq1B7LHF60Ir4QMtxJii5AXvW2J7hsSnZmk8=; b=fOBF16s+GyaSx71jaAWHk5ON/ilpS7B/irZvBRddj8n7cbS6OGncqeLHdvjRF4tW+yEIEhihe8YgmE6Bd14SFheVjiNIq1wk0noxU9VmNW471EEOOnDzNJI6WasQxp6y+cV503jR3KF9r2IS0ekRCuQ3ekE3SZKfn8GxJcV0OXg= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3783.eurprd08.prod.outlook.com (20.178.90.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Thu, 18 Apr 2019 11:59:31 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 11:59:31 +0000 From: Hannes Tschofenig To: "secdispatch@ietf.org" Thread-Topic: draft-selander-lake-reqs-01 Thread-Index: AdT12xxeCHrZt5W2T7qVHWoUx8oRMQ== Date: Thu, 18 Apr 2019 11:59:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3bd1eb0e-2d7d-4ba4-a2c1-08d6c3f5512c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB3783; x-ms-traffictypediagnostic: AM6PR08MB3783: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(136003)(39860400002)(346002)(396003)(376002)(189003)(199004)(40434004)(14444005)(81166006)(966005)(74316002)(476003)(1730700003)(7736002)(55016002)(26005)(72206003)(316002)(5024004)(6506007)(347745004)(256004)(14454004)(186003)(52536014)(3846002)(71190400001)(102836004)(21615005)(71200400001)(6116002)(86362001)(790700001)(97736004)(5640700003)(99286004)(8676002)(2906002)(606006)(7696005)(66066001)(68736007)(2501003)(6436002)(33656002)(478600001)(8936002)(54896002)(5660300002)(6306002)(9686003)(53936002)(236005)(6916009)(486006)(81156014)(2351001)(9326002)(25786009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3783; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KsiHBF3Gvj3zG7zPJPw6w8nt89NQmwRDjlhfleAfd9EDNfn0jU8sveMyWy+ydjj7WcRlg3x2Ucg1/A38wzPNWQ7jQLTFiYL7MIw3Zu2u/cUFQScxOfj/mZUqn3ETiDJk7TE0l/cfHWBXzca9BE3iCgMC594tDqSqJTKOUVES7ZwCZ+D0Ha2xt9C2mzdKQq5FXCOrxVUVI2thFVIB56G1EIvWWJepEBdvcM4I6zjT6Sv0OKLIRZ8q3TfFIV5NCXj3vNzKw1ff1XnifPuudtqRVUU34OJaAruaKJkYYp1Ib26WSeFyFiQVZV+0/xBLO9XvOtd6r2enmdMJgx7CNfC79skKQd5c7Pu+yRWpAuOZSMGNX3ccvdyCsppJzr+Jb9o4iF/0VLS21t6Dv5pMkbqN8j+lTnzYR+7sXjW2kBhQb70= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3686AE651F9058B71B9D686EFA260AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bd1eb0e-2d7d-4ba4-a2c1-08d6c3f5512c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 11:59:31.4216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3783 Archived-At: Subject: [Secdispatch] draft-selander-lake-reqs-01 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 11:59:36 -0000 --_000_AM6PR08MB3686AE651F9058B71B9D686EFA260AM6PR08MB3686eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Goeran, your draft makes the assumption we need OSCORE and hence a key management p= rotocol for it. It says that it is OSCORE [I-D.ietf-core-object-security] is a lightweight = communication security protocol providing end-to-end security for constrained IoT settings (cf. [RFC7228]). Should the draft say something about the weaker privacy properties compared= to the DTLS 1.3 record layer? You seem to have forgotten to mention those. Maybe it would also be good to state somewhere that OSCORE is heavier than = the DTLS 1.3 record layer (based on the analysis from your co-workers). If = we care about the bits over the wire so much we should probably be using th= e DTLS 1.3 record layer instead. Should it also state somewhere that these "end-to-end security" properties = only work under certain conditions? The name "Object Security for ..." may = give the uninformed reader the impression that it provides security at the = object level but instead it provides "provides end-to-end protection betwee= n endpoints communicating using CoAP or CoAP-mappable HTTP" - a kind of mes= sage level security. Particularly the CoAP-mappable HTTP part is interestin= g here because it requires the API on the CoAP side and the API on the HTTP= to be semantically equivalent. This does not appear to be the case in many= IoT deployments (for good reasons). Just look at the APIs vendors have pub= lished. (FWIW I am still waiting to see the API description of the Ericsson= IoT device management server. Ours is public and can be found here: https:= //www.pelion.com/docs/device-management/current/service-api-references/inde= x.html) It might also be a good idea to explore the CoAP proxy functionality again = because this is an often claimed area where OSCORE is needed. For those who= have not followed the CoAP work it is interesting to know that the design = of CoAP and HTTP differs also in the way proxies are used. A TLS connection= can traverse an HTTP proxy while in CoAP it terminates there. Maybe it is = time to integrate the properties of the HTTP proxy into CoAP? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB3686AE651F9058B71B9D686EFA260AM6PR08MB3686eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Goeran,

 

your draft makes the assumption= we need OSCORE and hence a key management protocol for it.

 

It says that it is <= /span>

 

   OSCORE [I-D.ietf-core-object-security] is a lightweight communic=
ation
   security protocol providing e=
nd-to-end security for constrained IoT
   settings (cf.  [RFC7228]).

 

Should the draft say something = about the weaker privacy properties compared to the DTLS 1.3 record layer? = You seem to have forgotten to mention those.

 

Maybe it would also be good to = state somewhere that OSCORE is heavier than the DTLS 1.3 record layer (base= d on the analysis from your co-workers). If we care about the bits over the= wire so much we should probably be using the DTLS 1.3 record layer instead.

 

Should it also state somewhere that these “end-t=
o-end security” properties only work under certain conditions? The na=
me “Object Security for …” may give the uninformed reader=
 the impression that it provides security at the object level but instead i=
t provides “provides end-to-end protection between endpoints communic=
ating using CoAP or CoAP-mappable HTTP” – a kind of message lev=
el security. Particularly the CoAP-mappable HTTP part is interesting here b=
ecause it requires the API on the CoAP side and the API on the HTTP to be s=
emantically equivalent. This does not appear to be the case in many IoT dep=
loyments (for good reasons). Just look at the APIs vendors have published. =
(FWIW I am still waiting to see the API description of the Ericsson IoT dev=
ice management server. Ours is public and can be found here: https://www.pelion.com/docs/d=
evice-management/current/service-api-references/index.html)
 
It might also be a good idea to explore the CoAP proxy=
 functionality again because this is an often claimed area where OSCORE is =
needed. For those who have not followed the CoAP work it is interesting to =
know that the design of CoAP and HTTP differs also in the way proxies are u=
sed. A TLS connection can traverse an HTTP proxy while in CoAP it terminate=
s there. Maybe it is time to integrate the properties of the HTTP proxy int=
o CoAP?

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB3686AE651F9058B71B9D686EFA260AM6PR08MB3686eurp_-- From nobody Thu Apr 18 05:12:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303CC1200A0 for ; Thu, 18 Apr 2019 05:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 S7EZkQdy_vX2 for ; Thu, 18 Apr 2019 05:12:00 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50075.outbound.protection.outlook.com [40.107.5.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC2B120052 for ; Thu, 18 Apr 2019 05:11:59 -0700 (PDT) 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=ClWJy+6VAMZD13JMIZXprUHx7jo+LpuPdObWkZXatQg=; b=LJBhb54KKBq49x4lsPj21O3ZuTsQWU6GnTsfi6lR7LmWiNoWCSajNGc2cWFS6BSMxFwHuVEnjP0DfqQRxL5+6gegGLiKdOp9zhQr2+82SSOFnZDjQx4QwgGFYNpZQtFD4USEKmQdFmF9+P3v4kUdn62DfGexHGUChbPB+Xmc6LU= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4267.eurprd07.prod.outlook.com (20.176.166.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 12:11:31 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 12:11:31 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwA= Date: Thu, 18 Apr 2019 12:11:31 +0000 Message-ID: <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.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.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 091197c8-dc03-4ac9-9cd3-08d6c3f6fe6d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4267; x-ms-traffictypediagnostic: HE1PR07MB4267: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(136003)(376002)(39860400002)(346002)(366004)(189003)(199004)(6116002)(86362001)(316002)(66574012)(110136005)(54906003)(58126008)(81156014)(81166006)(7736002)(4326008)(102836004)(6506007)(85202003)(186003)(8676002)(305945005)(4744005)(6486002)(85182001)(99286004)(8936002)(53936002)(6512007)(6246003)(82746002)(5660300002)(486006)(36756003)(68736007)(478600001)(14454004)(33656002)(256004)(446003)(6436002)(11346002)(2616005)(476003)(71200400001)(71190400001)(83716004)(229853002)(2906002)(76176011)(3846002)(26005)(97736004)(14444005)(25786009)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4267; H:HE1PR07MB4172.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-message-info: OFGVBHyMFRJSrif4haq9dAqaq6TIeDtXSDQ3DKICqMW41pOG7Pi6KJV/xYSQEs+iZ0wQfrMNcLbV+Q/aR8z84j44uxJ1qfANFHntrj8QSt16AkrNK/mEtSXGEB7kSrtbgpYT3W1SHTjhO7v/O20o21KkY1hXzWUNEkV/xCOz5romzM0xoxu+mnS9vvpxhlS0gCBaEWiRXup1bWz8lqDI+Gm1db8Cw1QXsnnflPGFd3OX6rt8zbSKSBRWmOELCyODUPaKPNn8w0IO7QV2N8wxq+wcNmTnnTstXyIjtdmwfpMIrfaEULmCM1poF/7wKz9IrYRjgjcCtbUwCatmRhVP9k2mGtGJmPH97EkNxtXqlMaAxd/ImLQdE67XATpTGwdGNh3WmD9duB9TzSzrJPDJXekKn74ys6Dk9pumbry9bG8= Content-Type: text/plain; charset="utf-8" Content-ID: <67058F8BFC3C4E45B81074AA7FD1B890@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 091197c8-dc03-4ac9-9cd3-08d6c3f6fe6d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:11:31.6380 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4267 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:12:02 -0000 SGkgSGFubmVzLA0KDQrvu79PbiAyMDE5LTA0LTE4LCAxMzowMSwgIkhhbm5lcyBUc2Nob2Zlbmln IiA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBHb2VyYW4sDQog ICAgDQogICAgIFtHU10gVGhlIEFLRSBmb3IgT1NDT1JFIGNsZWFybHkgbXVzdCBzdXBwb3J0IHRo ZSBzYW1lIHRyYW5zcG9ydCBhcyBPU0NPUkUuDQogICAgDQogICAgTm8sIGl0IGRvZXNuJ3QuDQoN CltHU10gU3RyaWtlICJjbGVhcmx5IiwgdGhpcyBpcyBhIHJlcXVpcmVtZW50IGNvbWluZyBmcm9t IHVzZSBjYXNlcyBpbXBsZW1lbnRpbmcgT1NDT1JFIGFuZCBpbiBuZWVkIGZvciBhbiBBS0UuDQog ICAgDQogICAgPiBGcm9tIGZpcnN0IGluZGl2aWR1YWwgc3VibWlzc2lvbiB0byB0aGUgYXBwcm92 ZWQgdmVyc2lvbiBvZiBPU0NPUkUsIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiBzdGF0ZXMgdGhh dCBPU0NPUkUgbWF5IG9yIG1heSBub3QgYmUgdXNlZCBvdmVyIFRMUy9EVExTLg0KICAgID4gKFRo ZSBhcHByb3ZlZCB2ZXJzaW9uIHJlY29tbWVuZHMgdGhlIHVzZSBvZiBhZGRpdGlvbmFsIFRMUyBm b3IgY2VydGFpbiBob3BzLCBidXQgbm90IG92ZXIgY29uc3RyYWluZWQgbmV0d29ya3MuKQ0KICAg IFlvdSBzZWUgd2hhdCBJIGFtIHRhbGtpbmcgYWJvdXQuLi4NCg0KW0dTXSBOby4gDQoNCiAgICA+ IE9TQ09SRS9BS0Ugb3ZlciBUTFMgaXMgc2ltaWxhciB0byBUTFMgb3ZlciBJUHNlYy9JS0V2Mi4N CiAgICBZb3Uga25vdyB0aGF0IG5vYm9keSB1c2VzIElQc2VjIC8gSUtFdjIgaW4gYW4gSW9UIGNv bnRleHQgKGV2ZW4gdGhvdWdoIHNvbWUgb2YgeW91ciBjby13b3JrZXJzIGV2ZW4gYXJndWVkIGZv ciBpdCBzb21lIHRpbWUgYWdvKS4NCiAgICANCltHU13CoFRoZSBhbmFsb2d5IEkgd2FudGVkIHRv IG1ha2UgaXMgdGhhdCBzZWN1cml0eSBwcm90b2NvbHMgbWF5IGJlIGFwcGxpZWQgYXQgbXVsdGlw bGUgbGF5ZXJzIG9uIGEgcGFydGljdWxhciBsZWcgb2YgYSBjb21tdW5pY2F0aW9uIHBhdGguDQpU aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggSW9UIGNvbnRleHQuDQoNCkfDtnJhbg0KDQogDQoN Cg== From nobody Thu Apr 18 05:12:26 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7141200A0 for ; Thu, 18 Apr 2019 05:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 22dTbZCUgPAm for ; Thu, 18 Apr 2019 05:12:22 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.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 6408F120052 for ; Thu, 18 Apr 2019 05:12:22 -0700 (PDT) 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=MYe2o7kGCZ9uYSDXK5Blm7C9QtWZrbkBrxliWtRXekk=; b=CpfDeIMvq6MOF1UflSi+uGZBz2lhYKZeNMri9wdeCcRYiEVMGJ+Qu74N4WgBnBhR5HGwFkIkE0tsTGYhmAUumcST+4qPequeFcBF4odCZyZ3h2vizk8FFLAMdaxnCSsIIY7FcK5TCaJIbwPizcwl7lcgLXrWOg+b2//BzZm4/l4= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4298.eurprd07.prod.outlook.com (20.176.166.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 12:12:18 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 12:12:18 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] draft-selander-lake-reqs-00: SDOs Thread-Index: AQHU9d/3tVxLgZoWr02AqYeMmVtV4A== Date: Thu, 18 Apr 2019 12:12:18 +0000 Message-ID: <28899015-6919-4A50-993E-1C06A8CD1645@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c542e113-9479-4442-d074-08d6c3f71a54 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4298; x-ms-traffictypediagnostic: HE1PR07MB4298: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(136003)(366004)(396003)(199004)(189003)(2906002)(6246003)(6116002)(2501003)(7736002)(83716004)(478600001)(5660300002)(36756003)(14454004)(71200400001)(3846002)(305945005)(6512007)(86362001)(66066001)(68736007)(53936002)(6306002)(316002)(97736004)(71190400001)(58126008)(102836004)(85202003)(33656002)(82746002)(229853002)(6486002)(186003)(256004)(26005)(25786009)(486006)(110136005)(476003)(6506007)(6436002)(85182001)(81166006)(99286004)(2616005)(8936002)(81156014)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4298; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VduYen1wsf3nsHHR5J2Avq699JDLMDaK33DpcE+jZJ2kNEckOIc1dZZN+l890ddZpoS+HJKdOALApRja3Ialx6vv1PFwC4QOmQQgNvqk9JgW8VNgaQ/Di+bVnULlvm1ELOrTVx2Q4xPegvsGuIAc/PoEiJZQWpnV2Y8EUqu3u4PzKGtoY7wO6PFSRokJJC+DnpIWNxQcsjS428OLJEyzEMBeEAgVJ2yJb91iQOq59R9SGXVFTQICdvuzeRTknHkRQCnafqsyvw0B75gUw6lB+zzOaaEQ9TU8wdML6F+l7bkRM10Joo21ptqby6QGY1VIktFvu/iQJD62QJDPXjQSEoZO2G7K0KQj+McvqUPLMwqZsWPBp0+uYTpgwcBaxJpDnjOY0UQVd5QCA6cUB1tGEHrYkRW7VUH3g6SuAAPOHdo= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c542e113-9479-4442-d074-08d6c3f71a54 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:12:18.3636 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4298 Archived-At: Subject: Re: [Secdispatch] draft-selander-lake-reqs-00: SDOs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:12:24 -0000 SGkgSGFubmVzLA0KDQrvu79PbiAyMDE5LTA0LTE4LCAxMzowNCwgIlNlY2Rpc3BhdGNoIG9uIGJl aGFsZiBvZiBIYW5uZXMgVHNjaG9mZW5pZyIgPHNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KDQogICAgSGkg R29lcmFuLCANCiAgICAgDQogICAgSSBhbSBub3QgYSBiaWcgZmFuIG9mIG1vdGl2YXRpbmcgd29y ayBieSByZWZlcmVuY2luZyB0byBvdGhlciBTRE9zDQogDQpbR1NdIEZpbmUsIHRoZXJlIGFyZSBJ RVRGIGludGVybmFsIHJlZmVyZW5jZXMgb2YgT1NDT1JFIHRvby4NCiAgICAgDQpXaHk/IEJlY2F1 c2UgaXQgaXMgbGFyZ2VseSBhIGZvcnVtIHNob3BwaW5nIGFjdGl2aXR5Li4NCg0KUGVvcGxlIGZy b20gb3RoZXIgU0RPcyBoYXZlIGJlZW4gZW5jb3VyYWdpbmcgdXMgdG8gYWRkIGRlc2lyZWQgZmVh dHVyZXMgKE9wZW4gQ29ubmVjdGl2aXR5IEZvdW5kYXRpb24pIGFuZCBvZmZlcmVkIGhlbHAgdG8g cHJvZ3Jlc3MgKEZhaXJoYWlyIEFsbGlhbmNlKS4gDQoNCk90aGVycyBvbiB0aGUgbGlzdCBtYXkg bm90IGtub3cgdGhhdCB5b3UgYnJvdWdodCBPU0NPUkUgdG8gdGhlIE9NQSAvIEx3TTJNIHYxLjEg c3BlY2lmaWNhdGlvbi4gSXQgaXMgYW4gb3B0aW9uYWwgZmVhdHVyZS4gWW91IHdyb3RlIHRoYXQg cGFydCBvZiB0aGUgc3BlY2lmaWNhdGlvbiwgaWYgSSByZWNhbGwgY29ycmVjdGx5Lg0KDQpbR1Nd IENvcnJlY3QuIExpa2UgRVNULUNvQVBzIGlzIGEgZmVhdHVyZSB5b3UgaGF2ZSBiZWVuIGRyaXZp bmcgaW4gYm90aCBJRVRGIGFuZCBPTUEgLyBMd00yTSB2MS4xLiANCiAgICAgDQogICAgICAgbyAg THdNMk0gdmVyc2lvbiAxLjEgW0x3TTJNIDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2VsYW5kZXItbGFrZS1yZXFzLTAwI3JlZi1Md00yTT5dLiAgTHdNMk0gdjEuMSBkZWZpbmVz IGJpbmRpbmdzIHRvIHR3byAgICAgIGNoYWxsZW5naW5nIHJhZGlvIHRlY2hub2xvZ2llcyB3aGVy ZSBPU0NPUkUgd2lsbCBiZSBkZXBsb3llZDogICAgICBMb1JhV0FOIGFuZCBOQi1Jb1QuICAgIA0K ICAgIFJlZ2FyZGluZyDigJzigKYgd2hlcmUgT1NDT1JFIHdpbGwgYmUgZGVwbG95ZWTigJ06IEp1 c3QgYmVjYXVzZSB5b3UgYWRkIGFuIG9wdGlvbmFsIGZlYXR1cmUgdG8gYSBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IGdldCBpdCBkZXBsb3llZC4NCg0KW0dTXSBJIGFtIGF3YXJlIG9mIGNvbXBhbmll cyBpbnZlc3RpbmcgaW4gT1NDT1JFIGZvciB0aGUgcHVycG9zZSBvZiBkZXBsb3lpbmcgaXQgd2l0 aCBMd00yTSBvdmVyIE5CLUlvVCBvciBMb1JhV0FOLg0KDQpHw7ZyYW4NCiAgICANCiAgIA0KDQoN Cg== From nobody Thu Apr 18 05:12:55 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7FB1202C4 for ; Thu, 18 Apr 2019 05:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 ZOuizGWixppX for ; Thu, 18 Apr 2019 05:12:51 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60079.outbound.protection.outlook.com [40.107.6.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658D8120052 for ; Thu, 18 Apr 2019 05:12:51 -0700 (PDT) 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=TeLcNNprQo8WsDR+AvcE0DzV+ygS6ARtPYCLG7CmnOY=; b=O7P9yaD3t5mnsAuftIXA91Cvy8P6hEkS78mpEXFw3DJL39D0TLZ9WdDbOISgBV48GEqzmim6tvYrAMXWs1H513+YpEN+D6kiB1bGKkPhO7pmY6esyPSBh4YCy6RWYrOdL58TvpOsvm9/ohgemMgxGdXBmxn6BzUusjEfgr/mCvE= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4428.eurprd07.prod.outlook.com (20.176.167.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 12:12:48 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 12:12:48 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] draft-selander-lake-reqs-01 Thread-Index: AQHU9eAJdsxmk9ZGfkS12AZfZjQ7hQ== Date: Thu, 18 Apr 2019 12:12:48 +0000 Message-ID: <91A5B7FE-93A5-46B0-8EED-45071444AC7F@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51664025-5c7c-42ca-9d88-08d6c3f72c15 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4428; x-ms-traffictypediagnostic: HE1PR07MB4428: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(136003)(39860400002)(189003)(199004)(40434004)(110136005)(305945005)(7736002)(6306002)(53936002)(86362001)(6246003)(6512007)(58126008)(97736004)(85182001)(36756003)(256004)(99286004)(5024004)(82746002)(14444005)(6506007)(85202003)(33656002)(68736007)(8676002)(316002)(966005)(66066001)(66574012)(83716004)(14454004)(102836004)(26005)(8936002)(25786009)(2501003)(81156014)(186003)(229853002)(5660300002)(347745004)(486006)(6116002)(3846002)(478600001)(6486002)(71190400001)(2616005)(476003)(2906002)(6436002)(71200400001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4428; H:HE1PR07MB4172.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-message-info: E129Hqm3QrEXQjqoKxCJ/WyCOC3WEZ0CCRRlDOwJeJsmzSQUCeOwq5qtVbpkhL4tveYueazpH5HkrEva2g80pPYVsDE9Br5yPEyPTq566STfB5dHoxZFpTVQiEtkQ094nABshlKHvo00tW/TpeB0OjFzPMOwEc5NDzknQRDS7m7BevbQKpUg505ajpuV+CVJSEx0GqFdblWL/EePV91FkHXpWjWtWarFdnqFPweZNwB3ygBFQobQzFtXFkpDdU4W5wRt1/M8MVPhzk+JD3RlUHlGVQtSUGPA/KJOs1VmBEMupRuo7a1zoDpvhFxtKd+7HCw1JjoWaPlICe0FOT99MmL4jZyr0N1QqsUU23URYqC5sFhh/5sWFe4YhTtepzk0hPlBYx6g590i4vM6bFfcKdkgCIq8ZKvI36xT08IIwhQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51664025-5c7c-42ca-9d88-08d6c3f72c15 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:12:48.1685 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4428 Archived-At: Subject: Re: [Secdispatch] draft-selander-lake-reqs-01 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:12:54 -0000 SGkgSGFubmVzLA0KDQpBcyBmYXIgYXMgSSB1bmRlcnN0YW5kIG5vbmUgb2YgdGhlIGNvbW1lbnRz IGluIHRoaXMgbWFpbCBhcmUgYWJvdXQgY3JpdGVyaWEgZm9yIHNlbGVjdGluZyBhIGtleSBleGNo YW5nZSBwcm90b2NvbCBmb3IgT1NDT1JFLg0KDQpHw7ZyYW4NCg0K77u/T24gMjAxOS0wNC0xOCwg MTM6NTksICJTZWNkaXNwYXRjaCBvbiBiZWhhbGYgb2YgSGFubmVzIFRzY2hvZmVuaWciIDxzZWNk aXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBIYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tPiB3cm90ZToNCg0KICAgIEhpIEdvZXJhbiwgDQogICAgIA0KICAgIHlvdXIgZHJhZnQg bWFrZXMgdGhlIGFzc3VtcHRpb24gd2UgbmVlZCBPU0NPUkUgYW5kIGhlbmNlIGEga2V5IG1hbmFn ZW1lbnQgcHJvdG9jb2wgZm9yIGl0Lg0KICAgIA0KICAgICANCiAgICBJdCBzYXlzIHRoYXQgaXQg aXMgDQogICAgIA0KICAgICAgIE9TQ09SRSBbSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkg PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1sYWtlLXJlcXMtMDEj cmVmLUktRC5pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5Pl0gaXMgYSBsaWdodHdlaWdodCBjb21t dW5pY2F0aW9uICAgc2VjdXJpdHkgcHJvdG9jb2wgcHJvdmlkaW5nIGVuZC10by1lbmQgc2VjdXJp dHkgZm9yIGNvbnN0cmFpbmVkIElvVCAgIHNldHRpbmdzIChjZi4gIFtSRkM3MjI4IDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIyOD5dKS4gDQogICAgU2hvdWxkIHRoZSBkcmFmdCBz YXkgc29tZXRoaW5nIGFib3V0IHRoZSB3ZWFrZXIgcHJpdmFjeSBwcm9wZXJ0aWVzIGNvbXBhcmVk IHRvIHRoZSBEVExTIDEuMyByZWNvcmQgbGF5ZXI/IFlvdSBzZWVtIHRvIGhhdmUgZm9yZ290dGVu IHRvIG1lbnRpb24gdGhvc2UuDQogICAgICAgDQogICAgTWF5YmUgaXQgd291bGQgYWxzbyBiZSBn b29kIHRvIHN0YXRlIHNvbWV3aGVyZSB0aGF0IE9TQ09SRSBpcyBoZWF2aWVyIHRoYW4gdGhlIERU TFMgMS4zIHJlY29yZCBsYXllciAoYmFzZWQgb24gdGhlIGFuYWx5c2lzIGZyb20geW91ciBjby13 b3JrZXJzKS4gSWYgd2UgY2FyZSBhYm91dCB0aGUgYml0cyBvdmVyIHRoZSB3aXJlIHNvIG11Y2gg d2Ugc2hvdWxkIHByb2JhYmx5IGJlDQogICAgIHVzaW5nIHRoZSBEVExTIDEuMyByZWNvcmQgbGF5 ZXIgaW5zdGVhZC4gDQogICAgIA0KICAgIFNob3VsZCBpdCBhbHNvIHN0YXRlIHNvbWV3aGVyZSB0 aGF0IHRoZXNlIOKAnGVuZC10by1lbmQgc2VjdXJpdHnigJ0gcHJvcGVydGllcyBvbmx5IHdvcmsg dW5kZXIgY2VydGFpbiBjb25kaXRpb25zPyBUaGUgbmFtZSDigJxPYmplY3QgU2VjdXJpdHkgZm9y IOKApuKAnSBtYXkgZ2l2ZSB0aGUgdW5pbmZvcm1lZCByZWFkZXIgdGhlIGltcHJlc3Npb24gdGhh dCBpdCBwcm92aWRlcyBzZWN1cml0eSBhdCB0aGUgb2JqZWN0IGxldmVsIGJ1dCBpbnN0ZWFkIGl0 IHByb3ZpZGVzIOKAnHByb3ZpZGVzIGVuZC10by1lbmQgcHJvdGVjdGlvbiBiZXR3ZWVuIGVuZHBv aW50cyBjb21tdW5pY2F0aW5nIHVzaW5nIENvQVAgb3IgQ29BUC1tYXBwYWJsZSBIVFRQ4oCdIOKA kyBhIGtpbmQgb2YgbWVzc2FnZSBsZXZlbCBzZWN1cml0eS4gUGFydGljdWxhcmx5IHRoZSBDb0FQ LW1hcHBhYmxlIEhUVFAgcGFydCBpcyBpbnRlcmVzdGluZyBoZXJlIGJlY2F1c2UgaXQgcmVxdWly ZXMgdGhlIEFQSSBvbiB0aGUgQ29BUCBzaWRlIGFuZCB0aGUgQVBJIG9uIHRoZSBIVFRQIHRvIGJl IHNlbWFudGljYWxseSBlcXVpdmFsZW50LiBUaGlzIGRvZXMgbm90IGFwcGVhciB0byBiZSB0aGUg Y2FzZSBpbiBtYW55IElvVCBkZXBsb3ltZW50cyAoZm9yIGdvb2QgcmVhc29ucykuIEp1c3QgbG9v ayBhdCB0aGUgQVBJcyB2ZW5kb3JzIGhhdmUgcHVibGlzaGVkLiAoRldJVyBJIGFtIHN0aWxsIHdh aXRpbmcgdG8gc2VlIHRoZSBBUEkgZGVzY3JpcHRpb24gb2YgdGhlIEVyaWNzc29uIElvVCBkZXZp Y2UgbWFuYWdlbWVudCBzZXJ2ZXIuIE91cnMgaXMgcHVibGljIGFuZCBjYW4gYmUgZm91bmQgaGVy ZTogaHR0cHM6Ly93d3cucGVsaW9uLmNvbS9kb2NzL2RldmljZS1tYW5hZ2VtZW50L2N1cnJlbnQv c2VydmljZS1hcGktcmVmZXJlbmNlcy9pbmRleC5odG1sIDxodHRwczovL3Byb3RlY3QyLmZpcmVl eWUuY29tL3VybD9rPThhY2NhMDhkLWQ2NDU3YWNhLThhY2NlMDE2LTBjYzQ3YWQ5M2MxOC05YzE2 YmJiMTA2YTljYzIyJnU9aHR0cHM6Ly93d3cucGVsaW9uLmNvbS9kb2NzL2RldmljZS1tYW5hZ2Vt ZW50L2N1cnJlbnQvc2VydmljZS1hcGktcmVmZXJlbmNlcy9pbmRleC5odG1sPikgSXQgbWlnaHQg YWxzbyBiZSBhIGdvb2QgaWRlYSB0byBleHBsb3JlIHRoZSBDb0FQIHByb3h5IGZ1bmN0aW9uYWxp dHkgYWdhaW4gYmVjYXVzZSB0aGlzIGlzIGFuIG9mdGVuIGNsYWltZWQgYXJlYSB3aGVyZSBPU0NP UkUgaXMgbmVlZGVkLiBGb3IgdGhvc2Ugd2hvIGhhdmUgbm90IGZvbGxvd2VkIHRoZSBDb0FQIHdv cmsgaXQgaXMgaW50ZXJlc3RpbmcgdG8ga25vdyB0aGF0IHRoZSBkZXNpZ24gb2YgQ29BUCBhbmQg SFRUUCBkaWZmZXJzIGFsc28gaW4gdGhlIHdheSBwcm94aWVzIGFyZSB1c2VkLiBBIFRMUyBjb25u ZWN0aW9uIGNhbiB0cmF2ZXJzZSBhbiBIVFRQIHByb3h5IHdoaWxlIGluIENvQVAgaXQgdGVybWlu YXRlcyB0aGVyZS4gTWF5YmUgaXQgaXMgdGltZSB0byBpbnRlZ3JhdGUgdGhlIHByb3BlcnRpZXMg b2YgdGhlIEhUVFAgcHJveHkgaW50byBDb0FQPyANCg0KDQoNCiAgICBDaWFvDQogICAgSGFubmVz DQogICAgDQogICAgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiAgICAgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K ICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 18 05:21:00 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B65120300 for ; Thu, 18 Apr 2019 05:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 C45HW8n4TR15 for ; Thu, 18 Apr 2019 05:20:55 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16077120052 for ; Thu, 18 Apr 2019 05:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aAxobwUpzDDHAfM24YLLHb7KHRNoZBjcN6fAP1WyNJg=; b=n7B9P0AY4J2alFrSjmAywBgCXJ1Om/jUUTcDOUVsg499fjODL6WwwY2XLtgsnBa2BaElUGutfLsIlfBHDghAxy//Wb1hWevPw0I86B3DvNBiMwX11kA/oZf7ZXGDwhlRLt9IoWlpreiQyu5kwRax35s+flEgToj56DLPES4wwd4= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4739.eurprd08.prod.outlook.com (10.255.97.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 12:20:51 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 12:20:51 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsA== Date: Thu, 18 Apr 2019 12:20:51 +0000 Message-ID: References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> In-Reply-To: <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff13daea-e62f-4838-edf6-08d6c3f84c36 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB4739; x-ms-traffictypediagnostic: AM6PR08MB4739: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(346002)(366004)(376002)(40434004)(189003)(199004)(476003)(66574012)(66066001)(97736004)(6246003)(76176011)(86362001)(229853002)(81166006)(8936002)(72206003)(9686003)(55016002)(81156014)(6436002)(110136005)(14454004)(7696005)(99286004)(478600001)(54906003)(8676002)(71200400001)(68736007)(71190400001)(53936002)(7736002)(305945005)(186003)(74316002)(446003)(256004)(5024004)(14444005)(316002)(26005)(25786009)(4326008)(102836004)(6506007)(11346002)(3846002)(33656002)(486006)(5660300002)(6116002)(2906002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4739; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PdpC2pnkGfoOeid+jdfYEoty+NpTS7aVWX94dUSSIPw64ooAOHzgcUJ2ywLTYJb/6mi4OlF5P2KVd+ZU3xoTXNnniMyTCEvZM25F4j2g08lKVwVW81yoVA1GW9BERySPaXojYC0Sqlv8zrvvB4JQJYryzpfcZXh81G4mtfXMxV40EhJJmLVe+JHPXLqZB0j2ZIpXTEgcpZPsyH0Xnf2JaBWB5pNOYf1ejHuOyXVuCJ+ItUVUUr4VFfrpI1PL9CxDybROYZuL7ln5c2sGu7Z9eBUOr4/QofrmnCIiriTVwajz296W61gugve4glswuvybYRqj1M9eJQ1CGsvMn3nRMBsjMmwMYGcHe/ELyydMa07QLMcq7k+AxX28DVxnklmO5uhlN3w+Z5eqfPnZdYAu/eBvdg7I5ttQ/noffEdIshk= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff13daea-e62f-4838-edf6-08d6c3f84c36 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:20:51.5846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4739 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:20:58 -0000 SGkgR29lcmFuLA0KDQoNCkhpIEhhbm5lcywNCg0K77u/T24gMjAxOS0wNC0xOCwgMTM6MDEsICJI YW5uZXMgVHNjaG9mZW5pZyIgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KDQog ICAgSGkgR29lcmFuLA0KDQogICAgIFtHU10gVGhlIEFLRSBmb3IgT1NDT1JFIGNsZWFybHkgbXVz dCBzdXBwb3J0IHRoZSBzYW1lIHRyYW5zcG9ydCBhcyBPU0NPUkUuDQoNCiAgICBObywgaXQgZG9l c24ndC4NCg0KW0dTXSBTdHJpa2UgImNsZWFybHkiLCB0aGlzIGlzIGEgcmVxdWlyZW1lbnQgY29t aW5nIGZyb20gdXNlIGNhc2VzIGltcGxlbWVudGluZyBPU0NPUkUgYW5kIGluIG5lZWQgZm9yIGFu IEFLRS4NCg0KW0hhbm5lc10gSSBkb24ndCBzZWUgd2hlcmUgdGhpcyByZXF1aXJlbWVudCBjb21l cyBmcm9tLiBGcm9tIHRoZSBEVExTL1RMUyBleHBlcmllbmNlIEkgaGF2ZSBzZWVuIHNldmVyYWwg c29sdXRpb25zIGluIHRoZSBJRVRGIHdoZXJlIHRoZSBoYW5kc2hha2Ugd2FzIHNlcGFyYXRlIGZy b20gdGhlIHByb3RlY3Rpb24gb2YgdGhlIGRhdGEuDQpJdCB3YXNuJ3QgYSBwcm9ibGVtIHRoZXJl Li4uDQoNCkkgYWN0dWFsbHkgc2VlIGFkdmFudGFnZXMgaWYgd2UgdW50YW5nbGUgaXQgZnJvbSB0 aGUgdHJhbnNwb3J0IGJlY2F1c2Ugd2Uga2VlcCBpbnZlbnRpbmcgbmV3IHRyYW5zcG9ydHMuIEZX SVcgSSBzZWUgUVVJQyBhcyBhIG5ldyB0cmFuc3BvcnQgYXMgd2VsbCBhbmQgb25lIHRoYXQgaGFz IG5vdCBiZWVuIGV4cGxvcmVkIGVub3VnaCBpbiB0aGUgSW9UIHNwYWNlLg0KDQogICAgPiBGcm9t IGZpcnN0IGluZGl2aWR1YWwgc3VibWlzc2lvbiB0byB0aGUgYXBwcm92ZWQgdmVyc2lvbiBvZiBP U0NPUkUsIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiBzdGF0ZXMgdGhhdCBPU0NPUkUgbWF5IG9y IG1heSBub3QgYmUgdXNlZCBvdmVyIFRMUy9EVExTLg0KICAgID4gKFRoZSBhcHByb3ZlZCB2ZXJz aW9uIHJlY29tbWVuZHMgdGhlIHVzZSBvZiBhZGRpdGlvbmFsIFRMUyBmb3IgY2VydGFpbiBob3Bz LCBidXQgbm90IG92ZXIgY29uc3RyYWluZWQgbmV0d29ya3MuKQ0KICAgIFlvdSBzZWUgd2hhdCBJ IGFtIHRhbGtpbmcgYWJvdXQuLi4NCg0KW0dTXSBOby4NCg0KW0hhbm5lc10gRmlyc3QgeW91IHNh eSAiaXQgbWF5IGJlIHVzZWQgb3ZlciBUTFMvRFRMUyIgZXZlbiBpbiB0aGUgZHJhZnQuIExhdGVy LCB5b3UgYWRkIHRoYXQgaXQgc2hvdWxkbid0IGJlIGRvbmUgb3ZlciBjb25zdHJhaW5lZCBuZXR3 b3Jrcy4gSSBhbSBzdXJlIEkgY2FuIGRpZyBvdXQgbWVldGluZyBtZWV0aW5ncyB3aGVyZSB5b3Ug ZGVueSB0aGF0IE9TQ09SRS9FREhPQyBhcmUgaW4gYW55IGNvbXBldGl0aW9uIHRvIFRMUy9EVExT Lg0KDQoNCiAgICA+IE9TQ09SRS9BS0Ugb3ZlciBUTFMgaXMgc2ltaWxhciB0byBUTFMgb3ZlciBJ UHNlYy9JS0V2Mi4NCiAgICBZb3Uga25vdyB0aGF0IG5vYm9keSB1c2VzIElQc2VjIC8gSUtFdjIg aW4gYW4gSW9UIGNvbnRleHQgKGV2ZW4gdGhvdWdoIHNvbWUgb2YgeW91ciBjby13b3JrZXJzIGV2 ZW4gYXJndWVkIGZvciBpdCBzb21lIHRpbWUgYWdvKS4NCg0KW0dTXSBUaGUgYW5hbG9neSBJIHdh bnRlZCB0byBtYWtlIGlzIHRoYXQgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBhcHBsaWVkIGF0 IG11bHRpcGxlIGxheWVycyBvbiBhIHBhcnRpY3VsYXIgbGVnIG9mIGEgY29tbXVuaWNhdGlvbiBw YXRoLg0KVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIElvVCBjb250ZXh0Lg0KDQpbSGFubmVz XSBCdXQgaXQgd2FzIGEgZ29vZCBleGFtcGxlIGJlY2F1c2UgYmFjayB0aGVuIEkgd2FzIGFsc28g dGhlIG9ubHkgb25lIHZvaWNpbmcgY29uY2VybnMgYWJvdXQgdGhlIGxhcmdlIG51bWJlciBvZiBz ZWN1cml0eSBvcHRpb25zIHdlIHByb3ZpZGUgaW4gdGhlIElvVCBzcGFjZS4gSXQgc2VlbXMgdGhh dCB5b3UgYWdyZWUgd2l0aCBtZSBpbiB0aGUgbWVhbndoaWxlLiBNb3JlIG9wdGlvbnMgZG9lcyBu b3QgbmVjZXNzYXJpbHkgbGVhZCB0byBiZXR0ZXIgaW50ZXJvcGVyYWJpbGl0eS4NCg0KQ2lhbw0K SGFubmVzDQoNCg0KR8O2cmFuDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMg b2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1h eSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Ns b3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJw b3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFu ayB5b3UuDQo= From nobody Thu Apr 18 05:30:31 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CACF12013D for ; Thu, 18 Apr 2019 05:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 Cukt8U7fgjak for ; Thu, 18 Apr 2019 05:30:28 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10088.outbound.protection.outlook.com [40.107.1.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F64B12004B for ; Thu, 18 Apr 2019 05:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4xehfluLSdeW/+P8CrG1qDmKfLL/uzOi9hiij12B9x4=; b=IK1o2a/HDnsqx1eOMRL6h+taEmfJ3kBek8rhqDSNrcGuIHB/Okbp56pLpa4UpNwZh2IvshkIo751TBc/tYZqNVTsziyerOtjEIppgyj11GMP0MOevZ4BsoWwnpxUVnJmmaGcpsZHgUjMUDsFlG6paqoYidn+vYsVopCOVuR6nKs= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3862.eurprd08.prod.outlook.com (20.178.90.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 12:30:25 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 12:30:25 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] draft-selander-lake-reqs-00: SDOs Thread-Index: AQHU9d/3tVxLgZoWr02AqYeMmVtV4KZB1qtg Date: Thu, 18 Apr 2019 12:30:24 +0000 Message-ID: References: <28899015-6919-4A50-993E-1C06A8CD1645@ericsson.com> In-Reply-To: <28899015-6919-4A50-993E-1C06A8CD1645@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebe95fee-81ec-4bc5-ecc4-08d6c3f9a1eb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB3862; x-ms-traffictypediagnostic: AM6PR08MB3862: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(366004)(39860400002)(40434004)(189003)(199004)(7736002)(446003)(14454004)(68736007)(99286004)(25786009)(7696005)(33656002)(97736004)(110136005)(81166006)(81156014)(478600001)(76176011)(2501003)(6306002)(53936002)(316002)(9686003)(6246003)(8936002)(72206003)(8676002)(86362001)(55016002)(52536014)(14444005)(71190400001)(256004)(5024004)(26005)(102836004)(186003)(71200400001)(229853002)(6116002)(3846002)(6436002)(486006)(11346002)(2906002)(66066001)(6506007)(5660300002)(74316002)(305945005)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3862; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: e3xRhqsCGURYgymitBIF+Y+O3DPrs2vEYaU4vARynbNxBxrjFfaFDTF0D7Ef/3OMhbCM0QoPDAFUjE+1kZQj8O7p6W9cPwfYob3M13WAtUs07vp7xbrjai6/f3rIbJtJ1Cg1q/uO8oRxTfmZd1PlLcAGw7dllDBa2EjuN9AVL/VeU0iEjBSpqQoBO2M7B02/r5ZZlMFNTs0wP0wLhrXEexmWvPGVYpJH+IbXmMQLQrDElB//7BNUBElcW0qjSbZcB5yGHnAeyJ2bNBXTtbmEBEismAR7DPkbqdNkP8zV738AL/WQfyphMWDhVoSntgGmysOv2LyKJVovNRbdth2auLy7hZccMj7o8zcOC8yYdmlAknN63l3CfwcenRafmgI4gmTXYO7M1L0vPakUoZroQ82EpkbYWhUh4q6IXeexBwo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebe95fee-81ec-4bc5-ecc4-08d6c3f9a1eb X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:30:24.9029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3862 Archived-At: Subject: Re: [Secdispatch] draft-selander-lake-reqs-00: SDOs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:30:30 -0000 SGkgR29lcmFuLA0KDQp+c25pcH4NCg0KIFtHU10gQ29ycmVjdC4gTGlrZSBFU1QtQ29BUHMgaXMg YSBmZWF0dXJlIHlvdSBoYXZlIGJlZW4gZHJpdmluZyBpbiBib3RoIElFVEYgYW5kIE9NQSAvIEx3 TTJNIHYxLjEuDQoNCi4uLi4gYW5kIGl0IGZpdHMgbmljZWx5IGludG8gdGhlIHN0cmF0ZWd5IHRv IHJlLXVzZSBEVExTLCB3aGljaCB3YXMgZm9yIGEgbG9uZyB0aW1lIHRoZSBzdG9yeSBmb3IgSW9U IGluIHRoZSBJRVRGKi4NCg0KVGhlIHJlZmVyZW5jZSB0byBFU1QtQ29BUHMgaXMsIGhvd2V2ZXIs IGJlc2lkZSB0aGUgcG9pbnQgSSBhbSB0cnlpbmcgdG8gbWFrZS4gVGVsbGluZyBvdGhlcnMgb24g dGhlIG1haWxpbmcgbGlzdCB0aGF0IHRoZXJlIGlzIHNvIG11Y2ggZGVtYW5kIHdoZW4geW91IGNy ZWF0ZWQgdGhhdCBkZW1hbmQgYnkgd3JpdGluZyB0aGUgc3BlYyBpbiBvdGhlciBvcmdhbml6YXRp b25zIGlzIGEgYml0IHRyaWNreS4NCg0KICAgICAgIG8gIEx3TTJNIHZlcnNpb24gMS4xIFtMd00y TSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWxha2UtcmVxcy0w MCNyZWYtTHdNMk0+XS4gIEx3TTJNIHYxLjEgZGVmaW5lcyBiaW5kaW5ncyB0byB0d28gICAgICBj aGFsbGVuZ2luZyByYWRpbyB0ZWNobm9sb2dpZXMgd2hlcmUgT1NDT1JFIHdpbGwgYmUgZGVwbG95 ZWQ6ICAgICAgTG9SYVdBTiBhbmQgTkItSW9ULg0KICAgIFJlZ2FyZGluZyDigJzigKYgd2hlcmUg T1NDT1JFIHdpbGwgYmUgZGVwbG95ZWTigJ06IEp1c3QgYmVjYXVzZSB5b3UgYWRkIGFuIG9wdGlv bmFsIGZlYXR1cmUgdG8gYSBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGdldCBpdCBkZXBsb3llZC4N Cg0KW0dTXSBJIGFtIGF3YXJlIG9mIGNvbXBhbmllcyBpbnZlc3RpbmcgaW4gT1NDT1JFIGZvciB0 aGUgcHVycG9zZSBvZiBkZXBsb3lpbmcgaXQgd2l0aCBMd00yTSBvdmVyIE5CLUlvVCBvciBMb1Jh V0FOLg0KDQpUZWxsIHRoZW0gd2UgYXJlIHVzaW5nIERUTFMgYW5kIGl0IHdvcmtzIGZpbmUuIFRo ZXkgY2FuIGNvbWUgYW5kIHRhbGsgdG8gdXMuIE91ciBjb2RlIGlzIGV2ZW4gb3BlbiBzb3VyY2Us IEFwYWNoZSAyLjAgbGljZW5zZS4NCg0KQ2lhbw0KSGFubmVzDQoNCigqKSBGcm9tIFJGQyA3NDUy ICJTbWFydCBPYmplY3QgQXJjaGl0ZWN0dXJhbCBDb25zaWRlcmF0aW9ucyINCg0KIg0KICBUbyBz aW1wbGlmeSB0aGUgZGV2ZWxvcG1lbnQgdGFzaywgYW5kIHRoZXJlYnkNCiAgIHRvIGxvd2VyIHRo ZSBjb3N0IG9mIGRldmVsb3BpbmcgbmV3IHByb2R1Y3RzIGFuZCBwcm90b3R5cGVzLCB3ZQ0KICAg YmVsaWV2ZSB0aGF0IHJldXNlIG9mIHByaW9yIHdvcmsgaXMgZXNzZW50aWFsLg0KIg0KDQoNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Apr 18 05:32:00 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F121202F6 for ; Thu, 18 Apr 2019 05:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 wCt3VpFBSOmk for ; Thu, 18 Apr 2019 05:31:56 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60063.outbound.protection.outlook.com [40.107.6.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9950912013D for ; Thu, 18 Apr 2019 05:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6IPnxcnhhL1A5AawrMjzyAe7flWHrH4BxtDeCJkFc0U=; b=MwYhiqIVg1dnCH3orTjUHEZRhqusxJoIOaoQnmA1Azqlyp7iuO1qeUDg9TEcpSzoQmJonNQRe2ZL5mWFAn9BCVKyL+nHvgGNzkxaANeRMG7zj2NXOM1H1jJUbKamLk8lCJw1pAslP7eXn7nTA4Zt8i8lklNsjYZG/w7xrlLbfu8= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4325.eurprd08.prod.outlook.com (20.179.6.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 12:31:54 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 12:31:54 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] draft-selander-lake-reqs-01 Thread-Index: AQHU9eAJdsxmk9ZGfkS12AZfZjQ7haZB2UsA Date: Thu, 18 Apr 2019 12:31:53 +0000 Message-ID: References: <91A5B7FE-93A5-46B0-8EED-45071444AC7F@ericsson.com> In-Reply-To: <91A5B7FE-93A5-46B0-8EED-45071444AC7F@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dfc1ee1e-c941-47e9-b5d6-08d6c3f9d6fd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4325; x-ms-traffictypediagnostic: AM6PR08MB4325: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(366004)(376002)(136003)(40434004)(13464003)(199004)(189003)(2906002)(52536014)(5024004)(14444005)(256004)(110136005)(6436002)(26005)(53546011)(8676002)(186003)(81166006)(102836004)(8936002)(476003)(81156014)(2501003)(6506007)(53936002)(33656002)(76176011)(486006)(7696005)(229853002)(316002)(97736004)(55016002)(5660300002)(6306002)(25786009)(446003)(6246003)(9686003)(11346002)(99286004)(66066001)(3846002)(6116002)(74316002)(66574012)(966005)(72206003)(7736002)(305945005)(71190400001)(71200400001)(68736007)(347745004)(86362001)(478600001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4325; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YamXbH+0KhvxI6CBl606640wy8chooLs46B1esOMTAWgYTbmXCe/27qi41EHxEmcPagzhcOJmy4crN+rbgOShhqn9sR1w/5bzRvP0d9bNLDoAIj8p5tswGu+W0hidw9TkPIbgwBtf5qaRVIULYzjdsdWs8MEBvCCnTWJMny3dtIRJVOS7BRQ/CqkY/7J6a1l8BhoK8SaEzX4Vba7RDMfbvNc84lU6z2N4l3RjE1qzz3N7+GKe7JtQi+BCAgnaEcLv3bQUwM68TGBCcJhTfJ0paq3jsmaA0sn+JuU0A06hI5xcp3/h2FXwsuysVk9hGbSgwe+qILe6vuNV4YK7Nmrex3tGFZloqo85FdH5Moe7ikm8ZBVn6NAdfQ4lcRI4N3gmboIU2zLjrdMOqSRH2rnREmIUHi/GG0N9b29uGpF5DE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfc1ee1e-c941-47e9-b5d6-08d6c3f9d6fd X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:31:53.9327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4325 Archived-At: Subject: Re: [Secdispatch] draft-selander-lake-reqs-01 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:31:59 -0000 SGkgR29lcmFuDQoNClRoZSBjb21tZW50cyBhZGRyZXNzIHlvdXIgcmVxdWlyZW1lbnQgdGhhdCBP U0NPUkUgbXVzdCBiZSB1c2VkLg0KSSBhbSBjaGFsbGVuZ2luZyB0aGlzIHJlcXVpcmVtZW50Lg0K DQpDaWFvDQpIYW5uZXMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR8O2 cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+DQpTZW50OiBEb25uZXJz dGFnLCAxOC4gQXByaWwgMjAxOSAxNDoxMw0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPjsgc2VjZGlzcGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb U2VjZGlzcGF0Y2hdIGRyYWZ0LXNlbGFuZGVyLWxha2UtcmVxcy0wMQ0KDQpIaSBIYW5uZXMsDQoN CkFzIGZhciBhcyBJIHVuZGVyc3RhbmQgbm9uZSBvZiB0aGUgY29tbWVudHMgaW4gdGhpcyBtYWls IGFyZSBhYm91dCBjcml0ZXJpYSBmb3Igc2VsZWN0aW5nIGEga2V5IGV4Y2hhbmdlIHByb3RvY29s IGZvciBPU0NPUkUuDQoNCkfDtnJhbg0KDQrvu79PbiAyMDE5LTA0LTE4LCAxMzo1OSwgIlNlY2Rp c3BhdGNoIG9uIGJlaGFsZiBvZiBIYW5uZXMgVHNjaG9mZW5pZyIgPHNlY2Rpc3BhdGNoLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3Rl Og0KDQogICAgSGkgR29lcmFuLA0KDQogICAgeW91ciBkcmFmdCBtYWtlcyB0aGUgYXNzdW1wdGlv biB3ZSBuZWVkIE9TQ09SRSBhbmQgaGVuY2UgYSBrZXkgbWFuYWdlbWVudCBwcm90b2NvbCBmb3Ig aXQuDQoNCg0KICAgIEl0IHNheXMgdGhhdCBpdCBpcw0KDQogICAgICAgT1NDT1JFIFtJLUQuaWV0 Zi1jb3JlLW9iamVjdC1zZWN1cml0eSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNlbGFuZGVyLWxha2UtcmVxcy0wMSNyZWYtSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHk+ XSBpcyBhIGxpZ2h0d2VpZ2h0IGNvbW11bmljYXRpb24gICBzZWN1cml0eSBwcm90b2NvbCBwcm92 aWRpbmcgZW5kLXRvLWVuZCBzZWN1cml0eSBmb3IgY29uc3RyYWluZWQgSW9UICAgc2V0dGluZ3Mg KGNmLiAgW1JGQzcyMjggPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjI4Pl0pLg0K ICAgIFNob3VsZCB0aGUgZHJhZnQgc2F5IHNvbWV0aGluZyBhYm91dCB0aGUgd2Vha2VyIHByaXZh Y3kgcHJvcGVydGllcyBjb21wYXJlZCB0byB0aGUgRFRMUyAxLjMgcmVjb3JkIGxheWVyPyBZb3Ug c2VlbSB0byBoYXZlIGZvcmdvdHRlbiB0byBtZW50aW9uIHRob3NlLg0KDQogICAgTWF5YmUgaXQg d291bGQgYWxzbyBiZSBnb29kIHRvIHN0YXRlIHNvbWV3aGVyZSB0aGF0IE9TQ09SRSBpcyBoZWF2 aWVyIHRoYW4gdGhlIERUTFMgMS4zIHJlY29yZCBsYXllciAoYmFzZWQgb24gdGhlIGFuYWx5c2lz IGZyb20geW91ciBjby13b3JrZXJzKS4gSWYgd2UgY2FyZSBhYm91dCB0aGUgYml0cyBvdmVyIHRo ZSB3aXJlIHNvIG11Y2ggd2Ugc2hvdWxkIHByb2JhYmx5IGJlDQogICAgIHVzaW5nIHRoZSBEVExT IDEuMyByZWNvcmQgbGF5ZXIgaW5zdGVhZC4NCg0KICAgIFNob3VsZCBpdCBhbHNvIHN0YXRlIHNv bWV3aGVyZSB0aGF0IHRoZXNlIOKAnGVuZC10by1lbmQgc2VjdXJpdHnigJ0gcHJvcGVydGllcyBv bmx5IHdvcmsgdW5kZXIgY2VydGFpbiBjb25kaXRpb25zPyBUaGUgbmFtZSDigJxPYmplY3QgU2Vj dXJpdHkgZm9yIOKApuKAnSBtYXkgZ2l2ZSB0aGUgdW5pbmZvcm1lZCByZWFkZXIgdGhlIGltcHJl c3Npb24gdGhhdCBpdCBwcm92aWRlcyBzZWN1cml0eSBhdCB0aGUgb2JqZWN0IGxldmVsIGJ1dCBp bnN0ZWFkIGl0IHByb3ZpZGVzIOKAnHByb3ZpZGVzIGVuZC10by1lbmQgcHJvdGVjdGlvbiBiZXR3 ZWVuIGVuZHBvaW50cyBjb21tdW5pY2F0aW5nIHVzaW5nIENvQVAgb3IgQ29BUC1tYXBwYWJsZSBI VFRQ4oCdIOKAkyBhIGtpbmQgb2YgbWVzc2FnZSBsZXZlbCBzZWN1cml0eS4gUGFydGljdWxhcmx5 IHRoZSBDb0FQLW1hcHBhYmxlIEhUVFAgcGFydCBpcyBpbnRlcmVzdGluZyBoZXJlIGJlY2F1c2Ug aXQgcmVxdWlyZXMgdGhlIEFQSSBvbiB0aGUgQ29BUCBzaWRlIGFuZCB0aGUgQVBJIG9uIHRoZSBI VFRQIHRvIGJlIHNlbWFudGljYWxseSBlcXVpdmFsZW50LiBUaGlzIGRvZXMgbm90IGFwcGVhciB0 byBiZSB0aGUgY2FzZSBpbiBtYW55IElvVCBkZXBsb3ltZW50cyAoZm9yIGdvb2QgcmVhc29ucyku IEp1c3QgbG9vayBhdCB0aGUgQVBJcyB2ZW5kb3JzIGhhdmUgcHVibGlzaGVkLiAoRldJVyBJIGFt IHN0aWxsIHdhaXRpbmcgdG8gc2VlIHRoZSBBUEkgZGVzY3JpcHRpb24gb2YgdGhlIEVyaWNzc29u IElvVCBkZXZpY2UgbWFuYWdlbWVudCBzZXJ2ZXIuIE91cnMgaXMgcHVibGljIGFuZCBjYW4gYmUg Zm91bmQgaGVyZTogaHR0cHM6Ly93d3cucGVsaW9uLmNvbS9kb2NzL2RldmljZS1tYW5hZ2VtZW50 L2N1cnJlbnQvc2VydmljZS1hcGktcmVmZXJlbmNlcy9pbmRleC5odG1sIDxodHRwczovL3Byb3Rl Y3QyLmZpcmVleWUuY29tL3VybD9rPThhY2NhMDhkLWQ2NDU3YWNhLThhY2NlMDE2LTBjYzQ3YWQ5 M2MxOC05YzE2YmJiMTA2YTljYzIyJnU9aHR0cHM6Ly93d3cucGVsaW9uLmNvbS9kb2NzL2Rldmlj ZS1tYW5hZ2VtZW50L2N1cnJlbnQvc2VydmljZS1hcGktcmVmZXJlbmNlcy9pbmRleC5odG1sPikg SXQgbWlnaHQgYWxzbyBiZSBhIGdvb2QgaWRlYSB0byBleHBsb3JlIHRoZSBDb0FQIHByb3h5IGZ1 bmN0aW9uYWxpdHkgYWdhaW4gYmVjYXVzZSB0aGlzIGlzIGFuIG9mdGVuIGNsYWltZWQgYXJlYSB3 aGVyZSBPU0NPUkUgaXMgbmVlZGVkLiBGb3IgdGhvc2Ugd2hvIGhhdmUgbm90IGZvbGxvd2VkIHRo ZSBDb0FQIHdvcmsgaXQgaXMgaW50ZXJlc3RpbmcgdG8ga25vdyB0aGF0IHRoZSBkZXNpZ24gb2Yg Q29BUCBhbmQgSFRUUCBkaWZmZXJzIGFsc28gaW4gdGhlIHdheSBwcm94aWVzIGFyZSB1c2VkLiBB IFRMUyBjb25uZWN0aW9uIGNhbiB0cmF2ZXJzZSBhbiBIVFRQIHByb3h5IHdoaWxlIGluIENvQVAg aXQgdGVybWluYXRlcyB0aGVyZS4gTWF5YmUgaXQgaXMgdGltZSB0byBpbnRlZ3JhdGUgdGhlIHBy b3BlcnRpZXMgb2YgdGhlIEhUVFAgcHJveHkgaW50byBDb0FQPw0KDQoNCg0KICAgIENpYW8NCiAg ICBIYW5uZXMNCg0KICAgIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogICAg IG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlv dS4NCg0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Apr 18 05:55:20 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1D112030B for ; Thu, 18 Apr 2019 05:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 RmI3dM3mnsKi for ; Thu, 18 Apr 2019 05:55:15 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130072.outbound.protection.outlook.com [40.107.13.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB5112030D for ; Thu, 18 Apr 2019 05:55:14 -0700 (PDT) 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=9AzAMmPgkHzmDU3zqeiVbEsGxv4HX5j+w5AWOf7ra5A=; b=MV3Wv23WI1n+1jNuPTeOD2BiTh2ArKEfP0kfiOlygxA7TbxsOm6em60bO9U2AZWWSG390apBItVtmH/VBOOyVW6EP4qHVKZbbvaGOldW9k6E0cQxjREvNyOuQpR8fEhRZNnqpVub2JGlxW/dj/cMz+0GUYjM0rFzwXhr6zHOdEE= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3100.eurprd07.prod.outlook.com (10.170.245.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.6; Thu, 18 Apr 2019 12:55:11 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 12:55:11 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsIAALWsA Date: Thu, 18 Apr 2019 12:55:11 +0000 Message-ID: <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.com> References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.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.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7047d356-9078-450d-6ecf-08d6c3fd17c1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3100; x-ms-traffictypediagnostic: HE1PR07MB3100: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(39860400002)(366004)(376002)(199004)(189003)(446003)(66066001)(229853002)(14454004)(26005)(186003)(8936002)(97736004)(478600001)(256004)(7736002)(14444005)(2616005)(6486002)(33656002)(99286004)(4326008)(93886005)(53936002)(11346002)(68736007)(5660300002)(85202003)(102836004)(66574012)(316002)(6436002)(6116002)(36756003)(76176011)(54906003)(110136005)(86362001)(85182001)(486006)(58126008)(81166006)(8676002)(81156014)(71200400001)(305945005)(2906002)(71190400001)(6246003)(476003)(3846002)(82746002)(6512007)(25786009)(6506007)(83716004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3100; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IIISckNkY/dY8gDLdPFYlxzxvYSqmcu0t/WypXTtquEWHsqpz4ISGCqHY9XnRy39ta0RzcTXLU6irlvodYWHylQ7euj1xttgkEqQ8M7Z1gSo60Ikm1Bu8ei6p8l/UK2vT+DCK7lLnij5es/MRogXdx8JVC+njmhjxteAW1WzmamrA+v8XULs0ZaAAMTzeX/97aBegmeFmfertWBa9LCfYUe9PwmF/UQ1aq/VgYAcAKoXJcxmKZDOP3xFYRX+zIvNSdvy62E/4FStc1Cu4g3zTdU+k4dLqfftSWak7LMTY4MZiTFotgQY8y42+1BocOOLA+2Oet7iG3Ri2U4qmpayCpz63l1Nw7/q1Z8PfXMcHNcNlAQk0X6zFlJj6XxVMse6MGyO9f4cr45GHxNMS8y2+B2kT8iwZgXiTbyIIp2FWuI= Content-Type: text/plain; charset="utf-8" Content-ID: <50CFDAB4696EB14EBB733CE30AFD55B1@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7047d356-9078-450d-6ecf-08d6c3fd17c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:55:11.1268 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3100 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:55:18 -0000 SGkgSGFubmVzLA0KDQrvu79PbiAyMDE5LTA0LTE4LCAxNDoyMSwgIlNlY2Rpc3BhdGNoIG9uIGJl aGFsZiBvZiBIYW5uZXMgVHNjaG9mZW5pZyIgPHNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KDQogICAgICAg ICBbR1NdIFRoZSBBS0UgZm9yIE9TQ09SRSBjbGVhcmx5IG11c3Qgc3VwcG9ydCB0aGUgc2FtZSB0 cmFuc3BvcnQgYXMgT1NDT1JFLg0KICAgIA0KICAgICAgICBObywgaXQgZG9lc24ndC4NCiAgICAN CiAgICBbR1NdIFN0cmlrZSAiY2xlYXJseSIsIHRoaXMgaXMgYSByZXF1aXJlbWVudCBjb21pbmcg ZnJvbSB1c2UgY2FzZXMgaW1wbGVtZW50aW5nIE9TQ09SRSBhbmQgaW4gbmVlZCBmb3IgYW4gQUtF Lg0KICAgIA0KICAgIFtIYW5uZXNdIEkgZG9uJ3Qgc2VlIHdoZXJlIHRoaXMgcmVxdWlyZW1lbnQg Y29tZXMgZnJvbS4gRnJvbSB0aGUgRFRMUy9UTFMgZXhwZXJpZW5jZSBJIGhhdmUgc2VlbiBzZXZl cmFsIHNvbHV0aW9ucyBpbiB0aGUgSUVURiB3aGVyZSB0aGUgaGFuZHNoYWtlIHdhcyBzZXBhcmF0 ZSBmcm9tIHRoZSBwcm90ZWN0aW9uIG9mIHRoZSBkYXRhLg0KICAgIEl0IHdhc24ndCBhIHByb2Js ZW0gdGhlcmUuLi4NCiAgICANCiAgICBJIGFjdHVhbGx5IHNlZSBhZHZhbnRhZ2VzIGlmIHdlIHVu dGFuZ2xlIGl0IGZyb20gdGhlIHRyYW5zcG9ydCBiZWNhdXNlIHdlIGtlZXAgaW52ZW50aW5nIG5l dyB0cmFuc3BvcnRzLiBGV0lXIEkgc2VlIFFVSUMgYXMgYSBuZXcgdHJhbnNwb3J0IGFzIHdlbGwg YW5kIG9uZSB0aGF0IGhhcyBub3QgYmVlbiBleHBsb3JlZCBlbm91Z2ggaW4gdGhlIElvVCBzcGFj ZS4NCg0KW0dTXSBUaGUgY29udGV4dCBpcyB0aGlzOiBPU0NPUkUgaXMgZGVwbG95ZWQgb3ZlciBh IG51bWJlciBvZiBob3BzIHdpdGggZGlmZmVyZW50IHRyYW5zcG9ydHMuIFRoZSBrZXkgZXhjaGFu Z2UgcHJvdG9jb2wgbXVzdCBhdCBsZWFzdCBiZSBhYmxlIHRvIHRyYXZlbCB0aGUgc2FtZSBwYXRo Lg0KICAgIA0KDQogICAgICAgID4gRnJvbSBmaXJzdCBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gdG8g dGhlIGFwcHJvdmVkIHZlcnNpb24gb2YgT1NDT1JFLCB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24g c3RhdGVzIHRoYXQgT1NDT1JFIG1heSBvciBtYXkgbm90IGJlIHVzZWQgb3ZlciBUTFMvRFRMUy4N CiAgICAgICAgPiAoVGhlIGFwcHJvdmVkIHZlcnNpb24gcmVjb21tZW5kcyB0aGUgdXNlIG9mIGFk ZGl0aW9uYWwgVExTIGZvciBjZXJ0YWluIGhvcHMsIGJ1dCBub3Qgb3ZlciBjb25zdHJhaW5lZCBu ZXR3b3Jrcy4pDQogICAgICAgIFlvdSBzZWUgd2hhdCBJIGFtIHRhbGtpbmcgYWJvdXQuLi4NCiAg ICANCiAgICBbR1NdIE5vLg0KICAgIA0KICAgIFtIYW5uZXNdIEZpcnN0IHlvdSBzYXkgIml0IG1h eSBiZSB1c2VkIG92ZXIgVExTL0RUTFMiIGV2ZW4gaW4gdGhlIGRyYWZ0LiBMYXRlciwgeW91IGFk ZCB0aGF0IGl0IHNob3VsZG4ndCBiZSBkb25lIG92ZXIgY29uc3RyYWluZWQgbmV0d29ya3MuIA0K DQpbR1NdIEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgeW91IGdvdCBmcm9tICJpdCBtYXkgYmUgdXNl ZCBvdmVyIFRMUy9EVExTIiB3aGljaCBoYXMgYmVlbiBzdGF0ZWQgaW4gdGhlIGRyYWZ0IHNpbmNl IGRheSAwIHRvICJpdCBtdXN0IGJlIHVzZWQgd2l0aCBUTFMvRFRMUyIgd2hpY2ggbmV2ZXIgaGFz IGJlZW4gc3RhdGVkIGluIHRoZSBkcmFmdC4gVGhlIGRyYWZ0IGRvZXMgbm90IHN0YXRlICJpdCBt dXN0L3Nob3VsZCBub3QgYmUgdXNlZCB3aXRoIFRMUy9EVExTIiAgLS0geW91IG1heSBkZXBsb3kg T1NDT1JFIGFuZCBUTFMvRFRMUyBpbiB0YW5kZW0gaWYgeW91IGxpa2UuDQoNCkkgYW0gc3VyZSBJ IGNhbiBkaWcgb3V0IG1lZXRpbmcgbWVldGluZ3Mgd2hlcmUgeW91IGRlbnkgdGhhdCBPU0NPUkUv RURIT0MgYXJlIGluIGFueSBjb21wZXRpdGlvbiB0byBUTFMvRFRMUy4NCiAgICANCltHU10gQmUg bXkgZ3Vlc3QuDQoNCiAgICANCiAgICAgICAgPiBPU0NPUkUvQUtFIG92ZXIgVExTIGlzIHNpbWls YXIgdG8gVExTIG92ZXIgSVBzZWMvSUtFdjIuDQogICAgICAgIFlvdSBrbm93IHRoYXQgbm9ib2R5 IHVzZXMgSVBzZWMgLyBJS0V2MiBpbiBhbiBJb1QgY29udGV4dCAoZXZlbiB0aG91Z2ggc29tZSBv ZiB5b3VyIGNvLXdvcmtlcnMgZXZlbiBhcmd1ZWQgZm9yIGl0IHNvbWUgdGltZSBhZ28pLg0KICAg IA0KICAgIFtHU10gVGhlIGFuYWxvZ3kgSSB3YW50ZWQgdG8gbWFrZSBpcyB0aGF0IHNlY3VyaXR5 IHByb3RvY29scyBtYXkgYmUgYXBwbGllZCBhdCBtdWx0aXBsZSBsYXllcnMgb24gYSBwYXJ0aWN1 bGFyIGxlZyBvZiBhIGNvbW11bmljYXRpb24gcGF0aC4NCiAgICBUaGlzIGhhcyBub3RoaW5nIHRv IGRvIHdpdGggSW9UIGNvbnRleHQuDQogICAgDQogICAgW0hhbm5lc10gQnV0IGl0IHdhcyBhIGdv b2QgZXhhbXBsZSBiZWNhdXNlIGJhY2sgdGhlbiBJIHdhcyBhbHNvIHRoZSBvbmx5IG9uZSB2b2lj aW5nIGNvbmNlcm5zIGFib3V0IHRoZSBsYXJnZSBudW1iZXIgb2Ygc2VjdXJpdHkgb3B0aW9ucyB3 ZSBwcm92aWRlIGluIHRoZSBJb1Qgc3BhY2UuIEl0IHNlZW1zIHRoYXQgeW91IGFncmVlIHdpdGgg bWUgaW4gdGhlIG1lYW53aGlsZS4gTW9yZSBvcHRpb25zIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGxl YWQgdG8gYmV0dGVyIGludGVyb3BlcmFiaWxpdHkuDQogICAgDQpbR1NdIEkgZGlkIG5vdCBtYWtl IGFueSBzdGF0ZW1lbnQgYWJvdXQgdGhlIHVzZSBvZiBJUHNlYyBmb3IgSW9ULiBJIGp1c3Qgd2Fu dGVkIHRvIGV4cGxhaW4gdGhlIGFuYWxvZ3kuDQoNCkfDtnJhbg0KDQoNCg0K From nobody Thu Apr 18 05:57:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BDD12030D for ; Thu, 18 Apr 2019 05:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 GbjemFxRGdLt for ; Thu, 18 Apr 2019 05:57:00 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DEA12030B for ; Thu, 18 Apr 2019 05:57:00 -0700 (PDT) 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=s3jqbDSpJycxUljmXarRXvZZInA0FROPJe/Dmj4AkJY=; b=Lhw1dScj6+t12ByPqcrDHimN5oNdUN2FwiQ2WTTNk1utLnZsE3qu9bNrvfzruUW2lYD9bWsas0qsulk565alncSH1OwjKw5wDHyy5Lp1taziEacTKvtAa7AvuqkSZ/+cSVQDz3xaF8UEttgP97jR2DOpEsf5bUw2Ly4IraOZKxA= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3100.eurprd07.prod.outlook.com (10.170.245.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.6; Thu, 18 Apr 2019 12:56:57 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 12:56:57 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] draft-selander-lake-reqs-00: SDOs Thread-Index: AQHU9d/3tVxLgZoWr02AqYeMmVtV4KZB1qtggAArgwA= Date: Thu, 18 Apr 2019 12:56:57 +0000 Message-ID: <051F5203-3523-4D27-9340-BECC86BB0A96@ericsson.com> References: <28899015-6919-4A50-993E-1C06A8CD1645@ericsson.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.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5ab4d99-0c78-4d52-d5e6-08d6c3fd5704 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3100; x-ms-traffictypediagnostic: HE1PR07MB3100: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(136003)(396003)(189003)(199004)(86362001)(58126008)(85182001)(486006)(316002)(76176011)(110136005)(2501003)(6436002)(36756003)(6116002)(25786009)(6512007)(82746002)(3846002)(476003)(83716004)(6506007)(81166006)(6246003)(71200400001)(4744005)(8676002)(81156014)(71190400001)(2906002)(305945005)(2616005)(7736002)(256004)(6486002)(33656002)(14454004)(66066001)(446003)(229853002)(478600001)(97736004)(26005)(186003)(8936002)(102836004)(53936002)(68736007)(11346002)(99286004)(85202003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3100; H:HE1PR07MB4172.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-message-info: F/PtV0gioE9y581LfiuwXRa0GLes1pDouZbHBtqFiKdrRSJLEm/BkPh6yFRraKya9ig4X6WgfeSo8K6/b9a212lY+Zrfyrr2DDMMsVEVke495JIQ2Fl+mWyv4EnW30aevQcCmhubNlATri3GgyJ0IHGt3F5YgxOd7nWFvccMN0xzjMnOySF7jO+Ds2FLuijjlD716EfuxXw21GkSa3ACZzWRc+kbYyLTDsIRHuyZsm1Fxe1Lpx2ibwLwX/sfDEWwUiipnyycp7sKHnpbc5bQrb9u4hI+8Zcbmh0Yo69Gj+GFVbxXrogQvARi99ITvO6NmfkNbVKv9f+7S51axDmGtLS4i7nrdY6Z95F48PgxPwey+ZoZvFeuTjPX/mlFqcbZan3tfW/O5VxMtqY0Qy3XDOtz/63HGIp9LnTWaBlF324= Content-Type: text/plain; charset="utf-8" Content-ID: <5903815200399942954B394150EB97D0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5ab4d99-0c78-4d52-d5e6-08d6c3fd5704 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:56:57.1779 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3100 Archived-At: Subject: Re: [Secdispatch] draft-selander-lake-reqs-00: SDOs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:57:02 -0000 SGkgSGFubmVzLA0KDQrvu79PbiAyMDE5LTA0LTE4LCAxNDozMSwgIlNlY2Rpc3BhdGNoIG9uIGJl aGFsZiBvZiBIYW5uZXMgVHNjaG9mZW5pZyIgPHNlY2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+IHdyb3RlOg0KDQogICAgSGkg R29lcmFuLA0KICAgIA0KICAgIH5zbmlwfg0KICAgIA0KICAgICBbR1NdIENvcnJlY3QuIExpa2Ug RVNULUNvQVBzIGlzIGEgZmVhdHVyZSB5b3UgaGF2ZSBiZWVuIGRyaXZpbmcgaW4gYm90aCBJRVRG IGFuZCBPTUEgLyBMd00yTSB2MS4xLg0KICAgIA0KICAgIC4uLi4gYW5kIGl0IGZpdHMgbmljZWx5 IGludG8gdGhlIHN0cmF0ZWd5IHRvIHJlLXVzZSBEVExTLCB3aGljaCB3YXMgZm9yIGEgbG9uZyB0 aW1lIHRoZSBzdG9yeSBmb3IgSW9UIGluIHRoZSBJRVRGKi4NCiAgICANCiAgICBUaGUgcmVmZXJl bmNlIHRvIEVTVC1Db0FQcyBpcywgaG93ZXZlciwgYmVzaWRlIHRoZSBwb2ludCBJIGFtIHRyeWlu ZyB0byBtYWtlLiBUZWxsaW5nIG90aGVycyBvbiB0aGUgbWFpbGluZyBsaXN0IHRoYXQgdGhlcmUg aXMgc28gbXVjaCBkZW1hbmQgd2hlbiB5b3UgY3JlYXRlZCB0aGF0IGRlbWFuZCBieSB3cml0aW5n IHRoZSBzcGVjIGluIG90aGVyIG9yZ2FuaXphdGlvbnMgaXMgYSBiaXQgdHJpY2t5Lg0KDQpbR1Nd IFRoZSBkZW1hbmQgaXMgdGhlcmUgaW5kZXBlbmRlbnRseSBvZiB3aG8gcHV0IHRoZSB0ZXh0IGlu dG8gdGhlIHN0YW5kYXJkLg0KDQpHw7ZyYW4NCiANCg0K From nobody Thu Apr 18 05:57:17 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D680912030D for ; Thu, 18 Apr 2019 05:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 yGdruAbcLKT8 for ; Thu, 18 Apr 2019 05:57:13 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD44812030B for ; Thu, 18 Apr 2019 05:57:12 -0700 (PDT) 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=zY2OcZY4JTr9eN3gjC+kyjRYoBIFcUx4kYl3nec93hQ=; b=WaPuEYb4xrj1lH7dLY3BdZBLIe8AxNNBu0ASm24mXxj9VOTa7Eteb3ZH6UO3q6iU0MOutO07lbXssQuGfX7yxrfnjMGnmkPBdvSlbu7J7o3t/Uw7IgCL+wuLBjcLB33A07/Dm+bNDZvvDdCais/h5E1RaL/T7PAYCoXDFXj+spI= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3100.eurprd07.prod.outlook.com (10.170.245.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.6; Thu, 18 Apr 2019 12:57:10 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 12:57:10 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] draft-selander-lake-reqs-01 Thread-Index: AQHU9eAJdsxmk9ZGfkS12AZfZjQ7haZB2UsAgAAo8oA= Date: Thu, 18 Apr 2019 12:57:10 +0000 Message-ID: <3301150B-E484-4909-A20E-C974BA0A14DD@ericsson.com> References: <91A5B7FE-93A5-46B0-8EED-45071444AC7F@ericsson.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.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9383d205-461d-4e8b-9883-08d6c3fd5eb6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3100; x-ms-traffictypediagnostic: HE1PR07MB3100: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(136003)(396003)(13464003)(40434004)(189003)(199004)(86362001)(58126008)(85182001)(486006)(316002)(76176011)(110136005)(6306002)(2501003)(6436002)(36756003)(6116002)(25786009)(6512007)(82746002)(3846002)(476003)(83716004)(6506007)(81166006)(6246003)(71200400001)(8676002)(81156014)(71190400001)(2906002)(305945005)(53546011)(2616005)(14444005)(7736002)(256004)(5024004)(6486002)(33656002)(14454004)(66066001)(66574012)(446003)(229853002)(478600001)(97736004)(26005)(186003)(8936002)(102836004)(347745004)(53936002)(68736007)(11346002)(99286004)(966005)(85202003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3100; H:HE1PR07MB4172.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-message-info: 9x6KvWmj6KVRJLqJUL0/WIgqS6fE8y+Mi3Jey5HFPfMexh9jcQJ1he/YnuQhM2nl5xxcAj5w3hGIw2r2jB/AMcGF6tXAxjFbYZZ1XznsYz1DgNFr5Ehj2HhKEUgwuqS47CGUfZLYEwlhFCJd/WnpvOiF4umSXXksBsFvFljScrZlTCJeyhi+PY99LtUoV45HxFvM2QFpcJ8OrPCzvSCZKkiP3MPtT+u7uVbCOtJzCEpi2dR3URcUxqi9Ezr75he01n38+ClQm9qoBWzLTR3krStTmPH6KGO2/fkR4Qv2O7wcG7B2BNWSO4D80Bzwe0zV9ez0ZQ8t1nHicJ2GGkbMzjxxeqH+IofYBKFw5DhQ7ulrx6p8ngdUOq/SMGndY1OV+wV7E8p0FZJcC2b/eFG0xsn3FDP4ums5AMl294ZVC+w= Content-Type: text/plain; charset="utf-8" Content-ID: <49F2EBA93F6E094294166EAAC110849D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9383d205-461d-4e8b-9883-08d6c3fd5eb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 12:57:10.1310 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3100 Archived-At: Subject: Re: [Secdispatch] draft-selander-lake-reqs-01 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 12:57:16 -0000 SGkgSGFubmVzLA0KDQpJJ20gYWZyYWlkIHRoYXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRp c2N1c3Npb24uIA0KDQpHw7ZyYW4NCg0K77u/T24gMjAxOS0wNC0xOCwgMTQ6MzIsICJTZWNkaXNw YXRjaCBvbiBiZWhhbGYgb2YgSGFubmVzIFRzY2hvZmVuaWciIDxzZWNkaXNwYXRjaC1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToN Cg0KICAgIEhpIEdvZXJhbg0KICAgIA0KICAgIFRoZSBjb21tZW50cyBhZGRyZXNzIHlvdXIgcmVx dWlyZW1lbnQgdGhhdCBPU0NPUkUgbXVzdCBiZSB1c2VkLg0KICAgIEkgYW0gY2hhbGxlbmdpbmcg dGhpcyByZXF1aXJlbWVudC4NCiAgICANCiAgICBDaWFvDQogICAgSGFubmVzDQogICAgDQogICAg DQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBHw7ZyYW4gU2VsYW5k ZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4NCiAgICBTZW50OiBEb25uZXJzdGFnLCAx OC4gQXByaWwgMjAxOSAxNDoxMw0KICAgIFRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRz Y2hvZmVuaWdAYXJtLmNvbT47IHNlY2Rpc3BhdGNoQGlldGYub3JnDQogICAgU3ViamVjdDogUmU6 IFtTZWNkaXNwYXRjaF0gZHJhZnQtc2VsYW5kZXItbGFrZS1yZXFzLTAxDQogICAgDQogICAgSGkg SGFubmVzLA0KICAgIA0KICAgIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQgbm9uZSBvZiB0aGUgY29t bWVudHMgaW4gdGhpcyBtYWlsIGFyZSBhYm91dCBjcml0ZXJpYSBmb3Igc2VsZWN0aW5nIGEga2V5 IGV4Y2hhbmdlIHByb3RvY29sIGZvciBPU0NPUkUuDQogICAgDQogICAgR8O2cmFuDQogICAgDQog ICAgT24gMjAxOS0wNC0xOCwgMTM6NTksICJTZWNkaXNwYXRjaCBvbiBiZWhhbGYgb2YgSGFubmVz IFRzY2hvZmVuaWciIDxzZWNkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBI YW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCiAgICANCiAgICAgICAgSGkgR29lcmFu LA0KICAgIA0KICAgICAgICB5b3VyIGRyYWZ0IG1ha2VzIHRoZSBhc3N1bXB0aW9uIHdlIG5lZWQg T1NDT1JFIGFuZCBoZW5jZSBhIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIGZvciBpdC4NCiAgICAN CiAgICANCiAgICAgICAgSXQgc2F5cyB0aGF0IGl0IGlzDQogICAgDQogICAgICAgICAgIE9TQ09S RSBbSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zZWxhbmRlci1sYWtlLXJlcXMtMDEjcmVmLUktRC5pZXRmLWNvcmUtb2JqZWN0 LXNlY3VyaXR5Pl0gaXMgYSBsaWdodHdlaWdodCBjb21tdW5pY2F0aW9uICAgc2VjdXJpdHkgcHJv dG9jb2wgcHJvdmlkaW5nIGVuZC10by1lbmQgc2VjdXJpdHkgZm9yIGNvbnN0cmFpbmVkIElvVCAg IHNldHRpbmdzIChjZi4gIFtSRkM3MjI4IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzIyOD5dKS4NCiAgICAgICAgU2hvdWxkIHRoZSBkcmFmdCBzYXkgc29tZXRoaW5nIGFib3V0IHRo ZSB3ZWFrZXIgcHJpdmFjeSBwcm9wZXJ0aWVzIGNvbXBhcmVkIHRvIHRoZSBEVExTIDEuMyByZWNv cmQgbGF5ZXI/IFlvdSBzZWVtIHRvIGhhdmUgZm9yZ290dGVuIHRvIG1lbnRpb24gdGhvc2UuDQog ICAgDQogICAgICAgIE1heWJlIGl0IHdvdWxkIGFsc28gYmUgZ29vZCB0byBzdGF0ZSBzb21ld2hl cmUgdGhhdCBPU0NPUkUgaXMgaGVhdmllciB0aGFuIHRoZSBEVExTIDEuMyByZWNvcmQgbGF5ZXIg KGJhc2VkIG9uIHRoZSBhbmFseXNpcyBmcm9tIHlvdXIgY28td29ya2VycykuIElmIHdlIGNhcmUg YWJvdXQgdGhlIGJpdHMgb3ZlciB0aGUgd2lyZSBzbyBtdWNoIHdlIHNob3VsZCBwcm9iYWJseSBi ZQ0KICAgICAgICAgdXNpbmcgdGhlIERUTFMgMS4zIHJlY29yZCBsYXllciBpbnN0ZWFkLg0KICAg IA0KICAgICAgICBTaG91bGQgaXQgYWxzbyBzdGF0ZSBzb21ld2hlcmUgdGhhdCB0aGVzZSDigJxl bmQtdG8tZW5kIHNlY3VyaXR54oCdIHByb3BlcnRpZXMgb25seSB3b3JrIHVuZGVyIGNlcnRhaW4g Y29uZGl0aW9ucz8gVGhlIG5hbWUg4oCcT2JqZWN0IFNlY3VyaXR5IGZvciDigKbigJ0gbWF5IGdp dmUgdGhlIHVuaW5mb3JtZWQgcmVhZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgaXQgcHJvdmlkZXMg c2VjdXJpdHkgYXQgdGhlIG9iamVjdCBsZXZlbCBidXQgaW5zdGVhZCBpdCBwcm92aWRlcyDigJxw cm92aWRlcyBlbmQtdG8tZW5kIHByb3RlY3Rpb24gYmV0d2VlbiBlbmRwb2ludHMgY29tbXVuaWNh dGluZyB1c2luZyBDb0FQIG9yIENvQVAtbWFwcGFibGUgSFRUUOKAnSDigJMgYSBraW5kIG9mIG1l c3NhZ2UgbGV2ZWwgc2VjdXJpdHkuIFBhcnRpY3VsYXJseSB0aGUgQ29BUC1tYXBwYWJsZSBIVFRQ IHBhcnQgaXMgaW50ZXJlc3RpbmcgaGVyZSBiZWNhdXNlIGl0IHJlcXVpcmVzIHRoZSBBUEkgb24g dGhlIENvQVAgc2lkZSBhbmQgdGhlIEFQSSBvbiB0aGUgSFRUUCB0byBiZSBzZW1hbnRpY2FsbHkg ZXF1aXZhbGVudC4gVGhpcyBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgdGhlIGNhc2UgaW4gbWFueSBJ b1QgZGVwbG95bWVudHMgKGZvciBnb29kIHJlYXNvbnMpLiBKdXN0IGxvb2sgYXQgdGhlIEFQSXMg dmVuZG9ycyBoYXZlIHB1Ymxpc2hlZC4gKEZXSVcgSSBhbSBzdGlsbCB3YWl0aW5nIHRvIHNlZSB0 aGUgQVBJIGRlc2NyaXB0aW9uIG9mIHRoZSBFcmljc3NvbiBJb1QgZGV2aWNlIG1hbmFnZW1lbnQg c2VydmVyLiBPdXJzIGlzIHB1YmxpYyBhbmQgY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHBzOi8vcHJv dGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9ZjE3OTY4YmQtYWRmMjYzODItZjE3OTI4MjYtODY4ZjI1 NzYxYjcyLTYyNDNiYzIxNTNkOTVhMWUmdT1odHRwczovL3d3dy5wZWxpb24uY29tL2RvY3MvZGV2 aWNlLW1hbmFnZW1lbnQvY3VycmVudC9zZXJ2aWNlLWFwaS1yZWZlcmVuY2VzL2luZGV4Lmh0bWwg PGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9OGFjY2EwOGQtZDY0NTdhY2EtOGFj Y2UwMTYtMGNjNDdhZDkzYzE4LTljMTZiYmIxMDZhOWNjMjImdT1odHRwczovL3d3dy5wZWxpb24u Y29tL2RvY3MvZGV2aWNlLW1hbmFnZW1lbnQvY3VycmVudC9zZXJ2aWNlLWFwaS1yZWZlcmVuY2Vz L2luZGV4Lmh0bWw+KSBJdCBtaWdodCBhbHNvIGJlIGEgZ29vZCBpZGVhIHRvIGV4cGxvcmUgdGhl IENvQVAgcHJveHkgZnVuY3Rpb25hbGl0eSBhZ2FpbiBiZWNhdXNlIHRoaXMgaXMgYW4gb2Z0ZW4g Y2xhaW1lZCBhcmVhIHdoZXJlIE9TQ09SRSBpcyBuZWVkZWQuIEZvciB0aG9zZSB3aG8gaGF2ZSBu b3QgZm9sbG93ZWQgdGhlIENvQVAgd29yayBpdCBpcyBpbnRlcmVzdGluZyB0byBrbm93IHRoYXQg dGhlIGRlc2lnbiBvZiBDb0FQIGFuZCBIVFRQIGRpZmZlcnMgYWxzbyBpbiB0aGUgd2F5IHByb3hp ZXMgYXJlIHVzZWQuIEEgVExTIGNvbm5lY3Rpb24gY2FuIHRyYXZlcnNlIGFuIEhUVFAgcHJveHkg d2hpbGUgaW4gQ29BUCBpdCB0ZXJtaW5hdGVzIHRoZXJlLiBNYXliZSBpdCBpcyB0aW1lIHRvIGlu dGVncmF0ZSB0aGUgcHJvcGVydGllcyBvZiB0aGUgSFRUUCBwcm94eSBpbnRvIENvQVA/DQogICAg DQogICAgDQogICAgDQogICAgICAgIENpYW8NCiAgICAgICAgSGFubmVzDQogICAgDQogICAgICAg IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogICAgICAgICBvciBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQogICAgDQog ICAgDQogICAgDQogICAgDQogICAgSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQogICAgU2VjZGlzcGF0Y2hAaWV0Zi5vcmcNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoDQogICAg DQoNCg== From nobody Thu Apr 18 06:46:00 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D498120159 for ; Thu, 18 Apr 2019 06:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Rq0L04iUD6tY for ; Thu, 18 Apr 2019 06:45:53 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450: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 F3DB6120334 for ; Thu, 18 Apr 2019 06:45:52 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id h18so1665652lfj.11 for ; Thu, 18 Apr 2019 06:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ryK04+SKt7tX14hhOjTAk5N9hPjirwAgBapb4n6wHVY=; b=Jn5yuM60kWhcBNmdYo9cGRQ+/vYGlxPfbZq0IKJlktkLIF+xB7KwAZQ+B8kXbB+uoj S0HNmhoWCJMoefvyu2iCp/aCM414hYD59alG3JxdeDcSE0DLOd7rLTjWtW+c8B3CzTj6 UKC/Tvdjn8rW1aNEaU8d5YlHpLJgSm8+6N2TF4Li4nTZrSXA5BV83RC/InAa2oaG3I7G KDN6/DgMUd9FitSGaFRv270CwhuETKxxjSJEyrZeamf4kZ+bwVSneAirZbUIFo3DWRLl pap9n6q8CzY9feQyUiwY/Sl+COb6e8RjFr4Nm/egq8rKoyjzH0EqqIL0+/3y2Xh0QAIo 3k6g== 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=ryK04+SKt7tX14hhOjTAk5N9hPjirwAgBapb4n6wHVY=; b=egO55tBp+4CIszDqRM96xnjj2879fClIhWiXlWgonf1ayQQVJcELKIbraP/UUvqLkA txEIPeH8rpqOa5YBNyV9Dzjm6JPmQ1lgMlf0sL/3ZvWiNR/gV3PmlyDRMnCZd17iFzhF iHWgOyB9BOd5QHH8AbYU1nNZWmCrEab/JekrGRYlUIonMG84oKYXMea/T/qBRjSz/MGv 7KUCLSAz76ONpV6U/BqbZeJpMKNUGJfGylr5CZ1ZOh+Hd/Y0Q+M90g7jzrVD4GloHVpn HlAzMLVDninLq1RvlgRzjON18hO4pHrDBJN2gyyMgd6uJDfe6GyFGGQ1S1UHORt6Vgq8 zSKw== X-Gm-Message-State: APjAAAU2M1cqB9nhFg+CkDcvyg4OOGUtVdOeNW6SftSLLEcm9Kp/d8Qo RHQ7JwPHLYGvxt/2t2K62fcvv4SOY4C2hotyEZ35xsGF X-Google-Smtp-Source: APXvYqwmvoRmz4PTthV/f9Sw5yI+sCSVUa2nNg3zu4xwfO1hD0ImFXp237W/Pm3jIstOISip1BLpUZFlLZ6SpPV87RY= X-Received: by 2002:a19:7911:: with SMTP id u17mr18951679lfc.90.1555595150957; Thu, 18 Apr 2019 06:45:50 -0700 (PDT) MIME-Version: 1.0 References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> In-Reply-To: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Eric Rescorla Date: Thu, 18 Apr 2019 06:45:10 -0700 Message-ID: To: Fernando Gont Cc: IETF SecDispatch , secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000063342d0586ce38e1" Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 13:45:59 -0000 --00000000000063342d0586ce38e1 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont wrote: > Folks, > > At the last secdispatch meeting I presented our I-D > draft-gont-predictable-numeric-ids. > > >From the meeting discussion, it would seem to me that there is support > for this work. > > It would also seem to me that part of this work is to be pursued in an > appropriate IRTF rg, while the update to RFC3552 > (draft-gont-numeric-ids-sec-considerations) should be pursued as an > AD-sponsored document. > I'm somewhat skeptical on an update to 3552; the proposed set of things to be improved seems unclear. I don't think that the material in this document should be added to 3552, as the purpose of 3552 is not really to go into that kind of detail about any specific topic. -Ekr > We're wondering how to proceed here. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --00000000000063342d0586ce38e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 16, 2019 at 2:07 AM Ferna= ndo Gont <fgont@si6networks.com= > wrote:
= Folks,

At the last secdispatch meeting I presented our I-D
draft-gont-predictable-numeric-ids.

>From the meeting discussion, it would seem to me that there is support<= br> for this work.

It would also seem to me that part of this work is to be pursued in an
appropriate IRTF rg, while the update to RFC3552
(draft-gont-numeric-ids-sec-considerations) should be pursued as an
AD-sponsored document.

I'm somewhat= skeptical on an update to 3552; the proposed set of things to be improved = seems unclear.

I don't think that the material= in this document should be added to 3552, as the purpose of 3552 is not re= ally to go into that kind of detail about any specific topic.

-Ekr


We're wondering how to proceed here.

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--00000000000063342d0586ce38e1-- From nobody Thu Apr 18 07:55:08 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD32120355 for ; Thu, 18 Apr 2019 07:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 UL9lrE-7Chcw for ; Thu, 18 Apr 2019 07:54:59 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150073.outbound.protection.outlook.com [40.107.15.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 F326A120356 for ; Thu, 18 Apr 2019 07:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zk7hFBcJFglAmihfETe7pRsY2IweTbe9F/iCGxzXZJ4=; b=a4ARY3KgbipGrHu943nPkDolQdpTFFSu+s2qBg+oqIRO7bI+xbbEP7twQBO2Ff9F1AdqT9YPCGBnN5EKmb4gWegK7vxxgrIs7Vqj+FdXmW/D3t9JV/SBI78hh73YkRG5+EOEbL11txnXGRnl5wCfplwRvcnDAQ5J2lL85tzvTYM= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4325.eurprd08.prod.outlook.com (20.179.6.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 14:54:54 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 14:54:54 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsIAALWsA////GOA= Date: Thu, 18 Apr 2019 14:54:54 +0000 Message-ID: References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.com> In-Reply-To: <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 420e54e7-b848-42af-55dd-08d6c40dd142 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4325; x-ms-traffictypediagnostic: AM6PR08MB4325: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(376002)(396003)(136003)(40434004)(189003)(199004)(2906002)(14444005)(52536014)(5024004)(256004)(110136005)(6436002)(54906003)(26005)(8676002)(186003)(81166006)(102836004)(8936002)(476003)(6506007)(53936002)(4326008)(33656002)(76176011)(81156014)(486006)(229853002)(7696005)(316002)(97736004)(55016002)(93886005)(5660300002)(25786009)(446003)(6246003)(9686003)(11346002)(99286004)(66066001)(3846002)(6116002)(4744005)(74316002)(72206003)(7736002)(305945005)(71190400001)(71200400001)(68736007)(86362001)(478600001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4325; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nXaGzqIp0GlD8qrOXfMqYmz9U6Ho+deQ/lD7R/l4gb1wkKHwahVcCjShDSyw0NQzcBkPPugFoSVNjuuFnl+LJEu252nN3XN0pdPUPAXXqpCJnU1/LvBwscFuhJZucI/R2MADT9GwW2OUeMi2J8s+ypgPmYebGlWheDWsmP6mo0onfL68WNscHYWfFR7oPLHGS0JdPrxnNPrCEHOmbjQZUzIm9IMUC6R5Pb8csTb1mEEY/H4Cq2eYdJx6KTYCoYDKG2W00lOlXD/qEYP8jG+Jmiof+2AYlJKfW1OimNQbQBb56tKPOMVnky3o/oEs/te8tyGYZmv37TSMUFIqsJFNBllGMgxaBdzRpzi4q5K0ZI64FREvvubqfX2yGevj37fpTYiuV9+hPFwOVBpXiEKGtaQBrwmPhc30t3eQ+e8W8xA= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 420e54e7-b848-42af-55dd-08d6c40dd142 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 14:54:54.2557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4325 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 14:55:02 -0000 SGkgR29lcmFuLA0KDQo+IFtHU10gVGhlIGNvbnRleHQgaXMgdGhpczogT1NDT1JFIGlzIGRlcGxv eWVkIG92ZXIgYSBudW1iZXIgb2YgaG9wcyB3aXRoIGRpZmZlcmVudCB0cmFuc3BvcnRzLiBUaGUg a2V5IGV4Y2hhbmdlIHByb3RvY29sIG11c3QgYXQgbGVhc3QgYmUgYWJsZSB0byB0cmF2ZWwgdGhl IHNhbWUgcGF0aC4NCg0KVGhpcyBpcyBub3cgYSBkaWZmZXJlbnQgcmVxdWlyZW1lbnQgdGhhbiBz dGF0ZWQgcHJldmlvdXNseS4gV2UgYXJlIG1ha2luZyBwcm9ncmVzcy4NCg0KQ2lhbw0KSGFubmVz DQoNClBTOiBJIHdvdWxkIGxpa2UgdG8gaGVhciBtb3JlIGFib3V0IHRoaXMgZGVwbG95bWVudCBv ZiBPU0NPUkUgb3ZlciBtdWx0aXBsZSBob3BzIHdpdGggZGlmZmVyZW50IHRyYW5zcG9ydHMuDQoN CklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Apr 18 08:07:43 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC217120355 for ; Thu, 18 Apr 2019 08:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 OrxlLyaPp3dk for ; Thu, 18 Apr 2019 08:07:39 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20082.outbound.protection.outlook.com [40.107.2.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE4A120170 for ; Thu, 18 Apr 2019 08:07:39 -0700 (PDT) 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=RJQ5cl78QYQ8wZQ3VxXLZ9JRUYBwexeKxDSgbk5YodA=; b=M2kggkPLI0+zJ9heJamUeEzpv0hpdVKwvjBJF1QDnrH2u3nw8qHBo4+eJBz3o9ZQ46b0nqK/T638rzOTke12miE8Z8Ho+xP54gQvbAuiVmn3smD8nXaDCOuGra/RPZuHxtpEDLvSlpfdpnUq2AiQqlUkrVnGYaa3TFEo1Y/tvN4= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4332.eurprd07.prod.outlook.com (20.176.167.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 15:07:35 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 15:07:35 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsIAALWsA////GOCAACXmAA== Date: Thu, 18 Apr 2019 15:07:35 +0000 Message-ID: <96AE0619-F977-42F1-8062-3FE9FECC6A13@ericsson.com> References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.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.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: babe1196-2240-4928-ba9e-08d6c40f96fd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4332; x-ms-traffictypediagnostic: HE1PR07MB4332: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(39860400002)(376002)(189003)(199004)(81166006)(97736004)(316002)(85182001)(99286004)(58126008)(305945005)(54906003)(85202003)(110136005)(81156014)(446003)(8676002)(83716004)(6506007)(476003)(71190400001)(7736002)(66574012)(2616005)(86362001)(186003)(71200400001)(256004)(11346002)(26005)(8936002)(4744005)(486006)(229853002)(6436002)(68736007)(2906002)(76176011)(6246003)(6512007)(5660300002)(25786009)(53936002)(6116002)(6486002)(33656002)(102836004)(478600001)(82746002)(3846002)(4326008)(93886005)(36756003)(66066001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4332; H:HE1PR07MB4172.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-message-info: 8dQ6UNuxbAtdqACKguWfnv7pUsSorQLcDMdBZQznKKqRvDrpaNcrbt5VTeryS/4a+XNNtXOJefb+Lpxjj/8HqBJJCkqLO8cBqYtVYLxY+XiGYsH7jQNGliwC1/r7Q9suCShL+6iGgKHk2eZ8o7GBASaHEi88NiiUFS05T7JY3Od2dhR8b5T4Yxm1QrI6K/ffHshYw7bUFMO67H0Em0/xB/2zO9MOOy5Yx3PzjAhc3akT84QWy1hlmH0eX5ZTRUm6dtCxuc8u+jqnkZZuyYBNVc2XUtHOYe8tKfe05TYI3b4Sr7ASZdSILpT0NCQ3lqy8NVcqqCS0hxBrxom6+zCFqEKx7rV6F297J1wkkQtOBIZ49EfiH8H9MQtEe8VatoQpMI12RTx/8wH8lgGjfxQGWsjG1lCV/S1O7z9E5wPzp7U= Content-Type: text/plain; charset="utf-8" Content-ID: <48234E29526E7A49919827B78C9B7E69@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: babe1196-2240-4928-ba9e-08d6c40f96fd X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 15:07:35.5187 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB4332 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:07:42 -0000 DQoNCu+7v09uIDIwMTktMDQtMTgsIDE2OjU1LCAiSGFubmVzIFRzY2hvZmVuaWciIDxIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCg0KICAgIEhpIEdvZXJhbiwNCiAgICANCiAgICA+ IFtHU10gVGhlIGNvbnRleHQgaXMgdGhpczogT1NDT1JFIGlzIGRlcGxveWVkIG92ZXIgYSBudW1i ZXIgb2YgaG9wcyB3aXRoIGRpZmZlcmVudCB0cmFuc3BvcnRzLiBUaGUga2V5IGV4Y2hhbmdlIHBy b3RvY29sIG11c3QgYXQgbGVhc3QgYmUgYWJsZSB0byB0cmF2ZWwgdGhlIHNhbWUgcGF0aC4NCiAg ICANCiAgICBUaGlzIGlzIG5vdyBhIGRpZmZlcmVudCByZXF1aXJlbWVudCB0aGFuIHN0YXRlZCBw cmV2aW91c2x5LiBXZSBhcmUgbWFraW5nIHByb2dyZXNzLg0KICAgDQpbR1NdIE5vLCB0aGlzIGlz IHRoZSByZXF1aXJlbWVudCAidGhlIEFLRSBzaG91bGQgc3VwcG9ydCB0aGUgc2FtZSB0cmFuc3Bv cnQgYXMgT1NDT1JFIi4gVGhhdCBkb2VzIG5vdCBleGNsdWRlIHRoYXQgdGhlIEFLRSBzdXBwb3J0 cyBvdGhlciB0cmFuc3BvcnQuDQoNCkfDtnJhbg0KDQoNCg== From nobody Thu Apr 18 08:17:47 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353FE1203BF for ; Thu, 18 Apr 2019 08:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 0hTZbQuF18-w for ; Thu, 18 Apr 2019 08:17:37 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00076.outbound.protection.outlook.com [40.107.0.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A2A12036B for ; Thu, 18 Apr 2019 08:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ac62AM8QT4KIIbAegen9yuWik/LJxm1tAVqE2MS/ks=; b=caB3Jjv2iwELmq5kjX/nTVP7AXbXKwUPFTdApwqnuTnx5vZ6darn0DLF8XyLdQLntM3k+g2x9lsu6SIeOtYkGS+kRazZCrXL/RGMsO8W9t25B1xAUtE9HGnwPC+PwEoYsf7heULY9ixKbzQR8CABj1oNyAvM0ioP1UWKFpM8us0= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3237.eurprd08.prod.outlook.com (52.135.164.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 15:17:34 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 15:17:34 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsIAALWsA////GOCAACXmAP//4EBQ Date: Thu, 18 Apr 2019 15:17:34 +0000 Message-ID: References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.com> <96AE0619-F977-42F1-8062-3FE9FECC6A13@ericsson.com> In-Reply-To: <96AE0619-F977-42F1-8062-3FE9FECC6A13@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 426563d5-8c52-4352-76e9-08d6c410fbdd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR08MB3237; x-ms-traffictypediagnostic: AM6PR08MB3237: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(136003)(39860400002)(40434004)(13464003)(199004)(189003)(52536014)(68736007)(97736004)(14454004)(478600001)(76176011)(5660300002)(102836004)(6506007)(99286004)(316002)(81156014)(186003)(486006)(53546011)(3846002)(11346002)(446003)(25786009)(8936002)(81166006)(6116002)(26005)(4326008)(53936002)(2906002)(55016002)(6246003)(5024004)(256004)(14444005)(54906003)(229853002)(9686003)(8676002)(305945005)(86362001)(6436002)(71190400001)(72206003)(7696005)(476003)(110136005)(33656002)(71200400001)(66574012)(74316002)(93886005)(66066001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3237; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6L6b8vSmKuvAbXw8wNtnkFC3pfhqvywWhdr9/NRDg7KoyBviU1jaYIzaNXWmeCgRhe1/mWcDwmL5eGKsHqSVnbVNvaAyox1JYsOU/SIHc62WytNWsGAJaPTWKguBIWhai9EY0fDzQxvn4qRwn+2QpN80Lrd8ZT83OO0DHCR/FFt93/zXRaQbvs2OVCUzdArCbcI618rsrvk0Zs3PVl9j+J7KBeLaV7hgD1YKiVzKhX04oLavSmiDrgeDcUb+5CCDoZgr058bG2z8dMNN9KfO3uIVcsz0Zd03s6m27buQ4RPRlCpmX/bv8IvT2Tr3lWBV2TBYlViZ8N0FbC/iRoFXqMKHGudgSfwQZVpTvW2kasqi1ZT6tuaeGsif9qDPKsf8pBARzYCdp9EklvzZeUqRkpxkzcFxBE0+YHXHFwPvEhw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 426563d5-8c52-4352-76e9-08d6c410fbdd X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 15:17:34.2869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3237 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:17:41 -0000 SGkgR29lcmFuLA0KDQpEbyB5b3Ugbm90aWNlIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVu DQoNCiJ0aGUgQUtFIHNob3VsZCBzdXBwb3J0IHRoZSBzYW1lIHRyYW5zcG9ydCBhcyBPU0NPUkUi DQoNCmFuZA0KDQoiVGhlIGtleSBleGNoYW5nZSBwcm90b2NvbCBtdXN0IGF0IGxlYXN0IGJlIGFi bGUgdG8gdHJhdmVsIHRoZSBzYW1lIHBhdGguIg0KDQpJZ25vcmluZyB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSAnc2hvdWxkJyBhbmQgdGhlICdtdXN0JyBJIHdvbmRlciB3aGV0aGVyIEkgY291 bGQgcnVuIGEgRFRMUy9UTFMgaGFuZHNoYWtlIGJldHdlZW4gdGhlIHR3byBlbmRwb2ludHMgYW5k IHRoZW4gZGVyaXZlIGtleXMgZm9yIE9TQ09SRSBhbmQgd2hldGhlciB0aGF0IHdvdWxkIHN0aWxs IGJlIE9LIGluIHlvdXIgdmlldy4NCg0KQ2lhbw0KSGFubmVzDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbT4NClNlbnQ6IERvbm5lcnN0YWcsIDE4LiBBcHJpbCAyMDE5IDE3OjA4DQpUbzogSGFubmVz IFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyBPd2VuIEZyaWVsIChvZnJp ZWwpIDxvZnJpZWxAY2lzY28uY29tPjsgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+OyBNaWNo YWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NCkNjOiBDYXJzdGVuIEJvcm1h bm4gPGNhYm9AdHppLm9yZz47IHNlY2Rpc3BhdGNoQGlldGYub3JnOyBNYXJ0aW4gVGhvbXNvbiA8 bXRAbG93ZW50cm9weS5uZXQ+DQpTdWJqZWN0OiBSZTogW1NlY2Rpc3BhdGNoXSBFREhPQyBTdW1t YXJ5DQoNCg0KDQrvu79PbiAyMDE5LTA0LTE4LCAxNjo1NSwgIkhhbm5lcyBUc2Nob2ZlbmlnIiA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBHb2VyYW4sDQoNCiAg ICA+IFtHU10gVGhlIGNvbnRleHQgaXMgdGhpczogT1NDT1JFIGlzIGRlcGxveWVkIG92ZXIgYSBu dW1iZXIgb2YgaG9wcyB3aXRoIGRpZmZlcmVudCB0cmFuc3BvcnRzLiBUaGUga2V5IGV4Y2hhbmdl IHByb3RvY29sIG11c3QgYXQgbGVhc3QgYmUgYWJsZSB0byB0cmF2ZWwgdGhlIHNhbWUgcGF0aC4N Cg0KICAgIFRoaXMgaXMgbm93IGEgZGlmZmVyZW50IHJlcXVpcmVtZW50IHRoYW4gc3RhdGVkIHBy ZXZpb3VzbHkuIFdlIGFyZSBtYWtpbmcgcHJvZ3Jlc3MuDQoNCltHU10gTm8sIHRoaXMgaXMgdGhl IHJlcXVpcmVtZW50ICJ0aGUgQUtFIHNob3VsZCBzdXBwb3J0IHRoZSBzYW1lIHRyYW5zcG9ydCBh cyBPU0NPUkUiLiBUaGF0IGRvZXMgbm90IGV4Y2x1ZGUgdGhhdCB0aGUgQUtFIHN1cHBvcnRzIG90 aGVyIHRyYW5zcG9ydC4NCg0KR8O2cmFuDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91Lg0K From nobody Thu Apr 18 08:30:30 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E78112038E for ; Thu, 18 Apr 2019 08:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 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, FROM_EXCESS_BASE64=0.979, 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 NhEO_tkUqXzV for ; Thu, 18 Apr 2019 08:30:27 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80049.outbound.protection.outlook.com [40.107.8.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C257E12008D for ; Thu, 18 Apr 2019 08:30:26 -0700 (PDT) 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=4mMZo+KTxiQyvVCY15zokgaU0BecSMwHrsPX6ZrLSjY=; b=MjBv82PfRBIC2yHATwuKwi63+O0eSkZbknhP7M4kfqZHsbQK74n88Xaar6EI66yv6hdjvSn1MZ3xdaUkIpS6yOoV4+vOEeClAiDgMAUFFnrjwZc7nj42+olr06XPlqS6KiKSwWrMMrw8MzmwWqGE78gkFzTRoIdECkTf2AX/Hes= Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3497.eurprd07.prod.outlook.com (10.170.247.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.7; Thu, 18 Apr 2019 15:30:23 +0000 Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::c587:c2ec:e227:84fd%4]) with mapi id 15.20.1835.007; Thu, 18 Apr 2019 15:30:23 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Hannes Tschofenig , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsIAALWsA////GOCAACXmAP//4EBQAATD4gA= Date: Thu, 18 Apr 2019 15:30:23 +0000 Message-ID: References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.com> <96AE0619-F977-42F1-8062-3FE9FECC6A13@ericsson.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.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com; x-originating-ip: [213.89.213.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bac71b44-5371-4e84-024c-08d6c412c641 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3497; x-ms-traffictypediagnostic: HE1PR07MB3497: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(39860400002)(396003)(40434004)(189003)(199004)(13464003)(99286004)(14444005)(256004)(6246003)(102836004)(2906002)(66066001)(82746002)(85202003)(54906003)(4326008)(36756003)(5024004)(110136005)(5660300002)(8936002)(478600001)(68736007)(966005)(6436002)(14454004)(305945005)(53546011)(6506007)(7736002)(97736004)(26005)(6512007)(76176011)(6306002)(25786009)(71200400001)(71190400001)(446003)(486006)(85182001)(33656002)(186003)(93886005)(476003)(2616005)(86362001)(66574012)(229853002)(53936002)(83716004)(58126008)(6486002)(11346002)(316002)(8676002)(81166006)(81156014)(3846002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3497; H:HE1PR07MB4172.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-message-info: am2HeFvTW2YIGxnVgGjLAMdcOENM0GW78YBofuiitvdy3K0QzVJWbCpVwj5w/1SuOtpkg7JWFM5RBRBXth4Mr4w6l9vfum0VpdItVXGUY10FboVRv2DGY1JKmvU4fIx6XLwzJJehz3aptw68ESbH9R35ZG92Wu2hu982lBtEjhpK5g/hOrGmN7nXTZgs9wRakB+eGSe8c19cScxG/T06HX23gEcNiqAupYskIqU2Ss9ocow6nv+H7xhhhBgMnKdnmsNifHhU0OipA14/k9RSJNApgVGNralLh5ybuBhK3fX3BuiBaY0aVKhq8d3zSlZ8FQcB7e/6gqwPl80O8VizD8GduQ5SG39nN2VssrF5g63ZTucTQD65XSA2zkx9jMuIbEvnmIYVQ5WiC818SC+PJK0pWOJNPaiJZ4oJ/np/h7M= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bac71b44-5371-4e84-024c-08d6c412c641 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 15:30:23.2967 (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-Transport-CrossTenantHeadersStamped: HE1PR07MB3497 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 15:30:29 -0000 SGkgSGFubmVzLA0KDQpXaHkgZG9uJ3QgeW91IGFuZCBJIGNlbGVicmF0ZSBFYXN0ZXIgdG9nZXRo ZXI/IFdlIHdpbGwgYmUgc3RheWluZyBpbiBhIG5pY2UgcGxhY2UsIHlvdSBhcmUgd2VsY29tZSB0 byBqb2luIGZvciBlbmRsZXNzIGRpc2N1c3Npb25zIF9fDQoNCu+7v09uIDIwMTktMDQtMTgsIDE3 OjE3LCAiU2VjZGlzcGF0Y2ggb24gYmVoYWxmIG9mIEhhbm5lcyBUc2Nob2ZlbmlnIiA8c2VjZGlz cGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgSGkgSGFubmVzLlRzY2hvZmVuaWdA YXJtLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBHb2VyYW4sDQogICAgDQogICAgRG8geW91IG5vdGlj ZSB0aGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2Vlbg0KICAgIA0KICAgICJ0aGUgQUtFIHNob3Vs ZCBzdXBwb3J0IHRoZSBzYW1lIHRyYW5zcG9ydCBhcyBPU0NPUkUiDQogICAgDQogICAgYW5kDQog ICAgDQogICAgIlRoZSBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgbXVzdCBhdCBsZWFzdCBiZSBhYmxl IHRvIHRyYXZlbCB0aGUgc2FtZSBwYXRoLiINCiAgICANCiAgICBJZ25vcmluZyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZSAnc2hvdWxkJyBhbmQgdGhlICdtdXN0JyANCg0KW0dTXSBTdXJlLCB0 aGVyZSBpcyBubyBncmFkaW5nIG9mIHRoZSByZXF1aXJlbWVudHMuDQoNCkkgd29uZGVyIHdoZXRo ZXIgSSBjb3VsZCBydW4gYSBEVExTL1RMUyBoYW5kc2hha2UgYmV0d2VlbiB0aGUgdHdvIGVuZHBv aW50cyBhbmQgdGhlbiBkZXJpdmUga2V5cyBmb3IgT1NDT1JFIGFuZCB3aGV0aGVyIHRoYXQgd291 bGQgc3RpbGwgYmUgT0sgaW4geW91ciB2aWV3Lg0KDQpbR1NdIFllcywgaWYgb3ZlciB0aGUgc2Ft ZSB0cmFuc3BvcnQuIA0KDQpHw7ZyYW4NCg0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQogICAgRnJvbTogR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb20+DQogICAgU2VudDogRG9ubmVyc3RhZywgMTguIEFwcmlsIDIwMTkgMTc6MDgNCiAgICBU bzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyBPd2VuIEZy aWVsIChvZnJpZWwpIDxvZnJpZWxAY2lzY28uY29tPjsgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYu c3g+OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NCiAgICBDYzog Q2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+OyBzZWNkaXNwYXRjaEBpZXRmLm9yZzsgTWFy dGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0Pg0KICAgIFN1YmplY3Q6IFJlOiBbU2VjZGlz cGF0Y2hdIEVESE9DIFN1bW1hcnkNCiAgICANCiAgICANCiAgICANCiAgICBPbiAyMDE5LTA0LTE4 LCAxNjo1NSwgIkhhbm5lcyBUc2Nob2ZlbmlnIiA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4g d3JvdGU6DQogICAgDQogICAgICAgIEhpIEdvZXJhbiwNCiAgICANCiAgICAgICAgPiBbR1NdIFRo ZSBjb250ZXh0IGlzIHRoaXM6IE9TQ09SRSBpcyBkZXBsb3llZCBvdmVyIGEgbnVtYmVyIG9mIGhv cHMgd2l0aCBkaWZmZXJlbnQgdHJhbnNwb3J0cy4gVGhlIGtleSBleGNoYW5nZSBwcm90b2NvbCBt dXN0IGF0IGxlYXN0IGJlIGFibGUgdG8gdHJhdmVsIHRoZSBzYW1lIHBhdGguDQogICAgDQogICAg ICAgIFRoaXMgaXMgbm93IGEgZGlmZmVyZW50IHJlcXVpcmVtZW50IHRoYW4gc3RhdGVkIHByZXZp b3VzbHkuIFdlIGFyZSBtYWtpbmcgcHJvZ3Jlc3MuDQogICAgDQogICAgW0dTXSBObywgdGhpcyBp cyB0aGUgcmVxdWlyZW1lbnQgInRoZSBBS0Ugc2hvdWxkIHN1cHBvcnQgdGhlIHNhbWUgdHJhbnNw b3J0IGFzIE9TQ09SRSIuIFRoYXQgZG9lcyBub3QgZXhjbHVkZSB0aGF0IHRoZSBBS0Ugc3VwcG9y dHMgb3RoZXIgdHJhbnNwb3J0Lg0KICAgIA0KICAgIEfDtnJhbg0KICAgIA0KICAgIA0KICAgIElN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFNlY2Rpc3BhdGNoIG1haWxpbmcg bGlzdA0KICAgIFNlY2Rpc3BhdGNoQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KICAgIA0KDQo= From nobody Thu Apr 18 09:35:08 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5653A1203BF for ; Thu, 18 Apr 2019 09:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=armh.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 PMN18DExVgtV for ; Thu, 18 Apr 2019 09:35:03 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30046.outbound.protection.outlook.com [40.107.3.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7564120412 for ; Thu, 18 Apr 2019 09:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rDDWDVUm0w+cGpAV96HK9E5qfP7KtzGmJuM4YVDBFgA=; b=rqNBeo2GTL3HqCKJsGVm1M/vIVJnmM+AoUrWpU3iS7sFEbMA03yJe8jJloc6EUBZLafAOtG+0K5EJX+4gheOdo52EvcHS4d72XcPUnMuxVFHIMuyyKZrweJLWYOvO67A32o0+PwqLL/9y8oFjYoZjGxAjKDMFbQoaLKBan8ddfk= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4615.eurprd08.prod.outlook.com (20.178.91.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.11; Thu, 18 Apr 2019 16:34:57 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 16:34:57 +0000 From: Hannes Tschofenig To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= , "Owen Friel (ofriel)" , Richard Barnes , Michael Richardson CC: Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9bryBp4FMEo1v0OmeS0uE21muKZBv2TQgAA2YwD//97IsIAALWsA////GOCAACXmAP//4EBQAATD4gAAAfa+sA== Date: Thu, 18 Apr 2019 16:34:56 +0000 Message-ID: References: <8BCAAD78-74D7-414C-82B2-EFB98D711D1E@ericsson.com> <2C9EADDC-2221-4321-9DE1-688DD7F97D34@ericsson.com> <0EE8E3B3-DCEE-4B23-8669-15F7080F73AF@ericsson.com> <96AE0619-F977-42F1-8062-3FE9FECC6A13@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 596034dd-5dd0-4917-f996-08d6c41bcb21 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4615; x-ms-traffictypediagnostic: AM6PR08MB4615: x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(40434004)(229853002)(186003)(3846002)(6436002)(33656002)(9686003)(55016002)(6506007)(93886005)(26005)(446003)(11346002)(2906002)(478600001)(6116002)(86362001)(14454004)(5024004)(4744005)(14444005)(256004)(76176011)(72206003)(102836004)(316002)(486006)(54906003)(110136005)(6246003)(97736004)(99286004)(52536014)(7736002)(25786009)(305945005)(71200400001)(71190400001)(476003)(81156014)(66066001)(81166006)(8936002)(7696005)(5660300002)(53936002)(4326008)(8676002)(74316002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4615; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: df3nJ3PTBOKXJ58thruSrIFNA6p/urzXy7QUJkS789PLcawheXBPQguuyVhJIuB6vIVZgHRNTocxrAu+kgqzwClTEbzkhEFEVPpv2KRMblVVVFQpd/kWEGyKp3C8xGU2zUUttMkcyOij3QmVa0nD/y/UmWMqOZWNQOjWrRiXCnsYaltzD37DeFkEVaNvAhnmyLXA3ZSCJ28p6Ruugs+FpZteDEkl4Cc4Iw3NJmk13O1ymcofrTAdohXZxeR6shFFyCBCEVqdV5+3Ef2uUYYowHAKYrnk4ma6HEaHUpT3zChy/LDWgmWq6uoYIsbNaqhafKJMxU8J+K8p79zrvDSSrQUMO0dw/wkKLLpZgEXK8SB7hbTbI+YBa4pj4U+2acCte+CSxCCcGsCt7fNJCtqwh/fFk3qJC80PsWpHbhdih3U= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 596034dd-5dd0-4917-f996-08d6c41bcb21 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 16:34:56.9875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4615 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 16:35:07 -0000 PiBXaHkgZG9uJ3QgeW91IGFuZCBJIGNlbGVicmF0ZSBFYXN0ZXIgdG9nZXRoZXI/IFdlIHdpbGwg YmUgc3RheWluZyBpbiBhIG5pY2UgcGxhY2UsIHlvdSBhcmUgd2VsY29tZSB0byBqb2luIGZvciBl bmRsZXNzIGRpc2N1c3Npb25zIF9fDQoNCkkgaGFkIHRvIGxhdWdoLiBMZXQncyBjb250aW51ZSBh ZnRlciB0aGUgRWFzdGVyIGhvbGlkYXkuDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRl bnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFu ZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91Lg0K From nobody Thu Apr 18 15:03:10 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E941203E1; Thu, 18 Apr 2019 15:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zno-a5voOs39; Thu, 18 Apr 2019 15:03:06 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E90B1203CD; Thu, 18 Apr 2019 15:03:06 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 692A383529; Fri, 19 Apr 2019 00:03:01 +0200 (CEST) To: Eric Rescorla Cc: IETF SecDispatch , secdispatch-chairs@ietf.org, pearg@irtf.org, =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Thu, 18 Apr 2019 23:50:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 22:03:09 -0000 On 18/4/19 15:45, Eric Rescorla wrote: > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > wrote: > > Folks, > > At the last secdispatch meeting I presented our I-D > draft-gont-predictable-numeric-ids. > > >From the meeting discussion, it would seem to me that there is support > for this work. > > It would also seem to me that part of this work is to be pursued in an > appropriate IRTF rg, while the update to RFC3552 > (draft-gont-numeric-ids-sec-considerations) should be pursued as an > AD-sponsored document. > > > I'm somewhat skeptical on an update to 3552; the proposed set of things > to be improved seems unclear. Can you please state what's unclear? We have 30+ years of history of screwing up numeric identifiers in the protocols we specify. Just to name a few: * TCP ISNs * TCP ephemeral ports * DNS TxIDs * IPv4 Frag IDs * IPv6 Frag IDs * IPv6 IIDs * NTP port numbers * NTP timestamps * TCP timestamps ... and the list can continue. We are trying, for once and for all, to act proactively in this respect, to avoid repeating the same history in every protocol we specify, and every implementation that comes up. > I don't think that the material in this document should be added to > 3552, as the purpose of 3552 is not really to go into that kind of > detail about any specific topic. What I would expect is that RFC3552 helps prevent us from coming up with vulnerable implementations. Clearly, the history of flawed IDs seems to indicate that we are doing something wrong. At the time of this writing, it seems that RFC3552 is the document that draft/RFC authors are required to read when it comes to how to do a security analysis of their document. So I am curious why you think this doesn't belong to RFC3552. That said, this document is *updating* RFC3552, rather than a revision of RFC3552. Therefore, the content in this document wouldn't become part of RFC3552, necessarily. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 18 16:10:03 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436E6120112 for ; Thu, 18 Apr 2019 16:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 4hPOWmovheWD for ; Thu, 18 Apr 2019 16:10:00 -0700 (PDT) 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 89525120136 for ; Thu, 18 Apr 2019 16:09:59 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id v13so3267540ljk.4 for ; Thu, 18 Apr 2019 16:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sEYEMm84h3igtMKzB2xfgQJ7xJpK71RGldxJmcFuIrY=; b=S0qrAxahJ1UElm1B1fGO795GD7bos3Dunf/0eJkwpIHGjovFe3K6OBR6RQiUS7rNhu 9Nm8yxa0hZSnhaoHzhqQhmkjPww1+iI+APnCO6kVa2poYLevpO29f4D2CSKIdI9CvBkN 0cJDkqEYWk14iFyBRJ6uYProg2vFkGsAXAulWhAtuTOmkk6GiZ7j41dMFS0CCbP1laRo /v5aPm50TPZi97n+Ey5T/Trq3s65M66KZtwFgiZLFK+h8DGvU5x8I3QEsCKFpZru/HJX TC/kV/iIWgXOnbSKN7fQ3ZvHS411kPHhANMMEKMh5En+MrHsYYkubsSpy35iG4eni9gA rj9A== 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=sEYEMm84h3igtMKzB2xfgQJ7xJpK71RGldxJmcFuIrY=; b=fglxnL0PxnM0iovavqE5t77LCI0Z9DjY5Sh/ty81ifZr3i0vEHe+Kz8j2WJWX+75j0 PkfyPMoraeJe0S2HcIxB2nUEMh1/R7/RvRN+1kbz0rh1RXaWBylUc9XTVns+/mknWV8Y 6vOkUsUK0ZL4ffzMKOZjyBopoWdBCNWIGlzNmBbiyF5MwnK7EY2byYmffYMj/xU4PtEh Y7taIYAjHhCe1kERNJ5YMhmaZSr2RVdUsDGJY3gf3J/cImHvGh+Psb1fiVd6uB9ukeA7 wPZ4itLkRW5sBtwYqnuqxjOzdJpDZJi3aA7Kux4RXkaEW+Cl0bTxm5C2kpsgsPMjSDM7 uJpQ== X-Gm-Message-State: APjAAAWoPPGKaSwflYfi7H2H8bv7gJIg7OAH4IUov7FrLKppbiCJVeEO Wa/AKy8dVtmyWqNYbBO3Z0+RNPgzEP+HGR9o+5z5kSgA X-Google-Smtp-Source: APXvYqzNFDLi4dRO5mmwNGyb8V2r6trFjdT3xd7sRSHMsEkiIJkIf22+qBo7yeeTAgn6vltMkWJ5n2vcBn4swO3h/0Q= X-Received: by 2002:a2e:81da:: with SMTP id s26mr426236ljg.86.1555628997590; Thu, 18 Apr 2019 16:09:57 -0700 (PDT) MIME-Version: 1.0 References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> In-Reply-To: From: Eric Rescorla Date: Thu, 18 Apr 2019 16:09:19 -0700 Message-ID: To: Fernando Gont Cc: =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000cdd5860586d619db" Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 23:10:02 -0000 --000000000000cdd5860586d619db Content-Type: text/plain; charset="UTF-8" On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont wrote: > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > wrote: > > > > Folks, > > > > At the last secdispatch meeting I presented our I-D > > draft-gont-predictable-numeric-ids. > > > > >From the meeting discussion, it would seem to me that there is > support > > for this work. > > > > It would also seem to me that part of this work is to be pursued in > an > > appropriate IRTF rg, while the update to RFC3552 > > (draft-gont-numeric-ids-sec-considerations) should be pursued as an > > AD-sponsored document. > > > > > > I'm somewhat skeptical on an update to 3552; the proposed set of things > > to be improved seems unclear. > > Can you please state what's unclear? > I understand the list of things in your document. However, there have been proposals for a larger revision to 3552. The proposed set of such revisions is unclear, and it's not clear to me why your document fits into such a revision. > > I don't think that the material in this document should be added to > > 3552, as the purpose of 3552 is not really to go into that kind of > > detail about any specific topic. > > What I would expect is that RFC3552 helps prevent us from coming up with > vulnerable implementations. This is not the purpose of 3552. Rather, it is to document what is required in a security considerations section in general (the threat model, an overview of common issues, etc.) rather than to go into detail about a specific kind of attack. Otherwise, the amount of detail would become impractical. Indeed, just covering the space of attacks on cryptographic protocols would be impractical. One might imagine that if there were a revision it would contain a paragraph or three on this topic, but nowhere near the 30-odd pages of material that is in this document, and I don't think it's independently a reason to do a 3552 revision. That said, this document is *updating* RFC3552, rather than a revision > of RFC3552. Therefore, the content in this document wouldn't become part > of RFC3552, necessarily. > Well, the semantics of "Updates" would be somewhat confusing here. Certainly I don't think that this document is something we need to transitively incorporate into 3552, but I care a lot less about the contents of this header than I do about whether 3552 should be updated to include this material. -Ekr Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000cdd5860586d619db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 3:03 PM Ferna= ndo Gont <fgont@si6networks.com= > wrote:
= On 18/4/19 15:45, Eric Rescorla wrote:
>
>
> On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont <fgont@si6networks.com
> <mailto:= fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Folks,
>
>=C2=A0 =C2=A0 =C2=A0At the last secdispatch meeting I presented our I-D=
>=C2=A0 =C2=A0 =C2=A0draft-gont-predictable-numeric-ids.
>
>=C2=A0 =C2=A0 =C2=A0>From the meeting discussion, it would seem to m= e that there is support
>=C2=A0 =C2=A0 =C2=A0for this work.
>
>=C2=A0 =C2=A0 =C2=A0It would also seem to me that part of this work is = to be pursued in an
>=C2=A0 =C2=A0 =C2=A0appropriate IRTF rg, while the update to RFC3552 >=C2=A0 =C2=A0 =C2=A0(draft-gont-numeric-ids-sec-considerations) should = be pursued as an
>=C2=A0 =C2=A0 =C2=A0AD-sponsored document.
>
>
> I'm somewhat skeptical on an update to 3552; the proposed set of t= hings
> to be improved seems unclear.

Can you please state what's unclear?

I understand the list of things in your document. However, there have bee= n proposals for a larger revision to 3552. The proposed set of such revisio= ns is unclear, and it's not clear to me why your document fits into suc= h a revision.

=C2=A0
> I don't think that the material in this document should be added t= o
> 3552, as the purpose of 3552 is not really to go into that kind of
> detail about any specific topic.

What I would expect is that RFC3552 helps prevent us from coming up with vulnerable implementations.

This is not the= purpose of 3552. Rather, it is to document what is required in a security = considerations section in general (the threat model, an overview of common = issues, etc.)=C2=A0 rather than to go into detail about a specific kind of = attack. Otherwise, the amount of detail would become impractical. Indeed, j= ust covering the space of attacks on cryptographic protocols would be impra= ctical. One might imagine that if there were a revision it would contain a = paragraph or three on this topic, but nowhere near the 30-odd pages of mate= rial that is in this document, and I don't think it's independently= a reason to do a 3552 revision.


That said, this document is *updating* RFC3552, rather than a revision
of RFC3552. Therefore, the content in this document wouldn't become par= t
of RFC3552, necessarily.

Well, the sema= ntics of "Updates" would be somewhat confusing here. Certainly I = don't think that this document is something we need to transitively inc= orporate into 3552, but I care a lot less about the contents of this header= than I do about whether 3552 should be updated to include this material.

-Ekr


Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000cdd5860586d619db-- From nobody Thu Apr 18 16:40:23 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF661201B9; Thu, 18 Apr 2019 16:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 BVg_e1T0Ot-k; Thu, 18 Apr 2019 16:40:19 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6811201B7; Thu, 18 Apr 2019 16:40:19 -0700 (PDT) Received: from [192.168.3.138] (unknown [186.138.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5A22E8493B; Fri, 19 Apr 2019 01:40:10 +0200 (CEST) To: Eric Rescorla Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 01:39:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 23:40:22 -0000 On 19/4/19 01:09, Eric Rescorla wrote: > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > wrote: > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > >> wrote: > > > >     Folks, > > > >     At the last secdispatch meeting I presented our I-D > >     draft-gont-predictable-numeric-ids. > > > >     >From the meeting discussion, it would seem to me that there > is support > >     for this work. > > > >     It would also seem to me that part of this work is to be > pursued in an > >     appropriate IRTF rg, while the update to RFC3552 > >     (draft-gont-numeric-ids-sec-considerations) should be pursued > as an > >     AD-sponsored document. > > > > > > I'm somewhat skeptical on an update to 3552; the proposed set of > things > > to be improved seems unclear. > > Can you please state what's unclear? > > > I understand the list of things in your document. However, there have > been proposals for a larger revision to 3552. There was an effort to revise RFC3552. It just didn't happen. Looks like trying to boil the ocean wasn't the best idea. > > I don't think that the material in this document should be added to > > 3552, as the purpose of 3552 is not really to go into that kind of > > detail about any specific topic. > > What I would expect is that RFC3552 helps prevent us from coming up with > vulnerable implementations. > > > This is not the purpose of 3552. Rather, it is to document what is > required in a security considerations section in general (the threat > model, an overview of common issues, etc.)  rather than to go into > detail about a specific kind of attack. Otherwise, the amount of detail > would become impractical. Indeed, just covering the space of attacks on > cryptographic protocols would be impractical. One might imagine that if > there were a revision it would contain a paragraph or three on this > topic, but nowhere near the 30-odd pages of material that is in this > document, and I don't think it's independently a reason to do a 3552 > revision. You seem to be looking at the wrong document. The document in question is this one: https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations-03 It's a total of 9 pages. If you remove abstract, boilerplate, and references, you end up with ~4 pages. In fact, the update (and indispensable text) is that in Section 5, and boils down to: ---- cut here ---- 5. Security and Privacy Requirements for Identifiers Protocol specifications that specify transient numeric identifiers MUST: 1. Clearly specify the interoperability requirements for the aforementioned identifiers. 2. Provide a security and privacy analysis of the aforementioned identifiers. 3. Recommend an algorithm for generating the aforementioned identifiers that mitigates security and privacy issues, such as those discussed in [I-D.gont-predictable-numeric-ids]. ---- cut here ---- > That said, this document is *updating* RFC3552, rather than a revision > of RFC3552. Therefore, the content in this document wouldn't become part > of RFC3552, necessarily. > > > Well, the semantics of "Updates" would be somewhat confusing here. > Certainly I don't think that this document is something we need to > transitively incorporate into 3552, but I care a lot less about the > contents of this header than I do about whether 3552 should be updated > to include this material. I do think RFC3552 should be updated as indicated (this stuff is general enough to be covered there). That said, the high-order bit here is to do something to prevent the bad history we have wrt numeric ids from repeating itself. If the whole point is that you'd like the "Updates: 3552 (if approved)" header to be removed (along with references to "updating RFC3552"), please say so. What we care about is to produce a change in what specifications do with respect to numeric ids, rather than that what specific document we are updating. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 18 17:02:01 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA72120359 for ; Thu, 18 Apr 2019 17:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 2i1_jqvFBRCX for ; Thu, 18 Apr 2019 17:01:58 -0700 (PDT) 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 CF251120248 for ; Thu, 18 Apr 2019 17:01:57 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id a28so2871221lfo.7 for ; Thu, 18 Apr 2019 17:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZR06E1KKi5fk9z6VbFWIOqyBg6/3600xLE1kv6N4gA=; b=b3xc0+s0t0xaDlDyyaV4tJpkGl26T9jPinwi5LcpA/TCKPhM+wYjir3MdKx8wGhHH4 ayoRmNRJII0YeWsmRhl1Oxddq60ASNw/DzMo8nOg1iuS6Q7APErLxJeWu0FTdMtQkiDi CHMivaoth+D6Yy0vt2N0CjedU2u6ZmJodxyQr/wDJ77/iwuV9WSegzgh+KH+ew0abvmM jAfSCHTOxEmJpKhTeiTijbF9Y2+EO8hCm/lNl8+Cst0Yc3pTUKB5JgjyLgP7067a4The aNKFMXogO/Zcr9IUdleB9X9OntyVj9X2JKaNso9elT0p0WbRvTZ0pVmEQ3JZmd86FspG bFMQ== 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=fZR06E1KKi5fk9z6VbFWIOqyBg6/3600xLE1kv6N4gA=; b=nZVung+MuYDJ4frD7uAV9GZSGk/f0JyX3k691tbvtFytKwmhnnFRP4RYglr/6LK3cp fVSigBdad0VcMsNboAaPoqXd5Ft8XruE+aiY5xux98t/E+AjlHBahpWeTaDipcKylaHk LAbJUWQhuLknJh87DBPxInYVK/kiL855ws749vrxUxLDWcPJwi5kHrdCrs6QxmeN1fX7 cBgwJfr1x368I7EUR6nkAOt0F5BHgz0JxYCOOXVcbEty7LLP5cTVDHIMFcGIEz/wAAzp hvyAcVJn2VMVVgNDQalYaJEbo7xEkq5cLr8YdPlf5HX69my0m+64xlyv8cOOaCFfTgXB lI+Q== X-Gm-Message-State: APjAAAUnAPjToBaIFIO+yVkBk+wIsQGjDoekJOBRCFbk/bk9IVQrrLIK k2ZQy99RxsiOkj4pAaaGHx+p/PQk0hUFpRkszaVllw== X-Google-Smtp-Source: APXvYqy9z+5EeVagtlO3+rIoSI1xyQCC9z2c95QHHCV/UFPVOqmBacpNHpsLo81YB7PkeUXqOUf3vj77MEcPKCYGK8Y= X-Received: by 2002:ac2:55b2:: with SMTP id y18mr477213lfg.133.1555632115987; Thu, 18 Apr 2019 17:01:55 -0700 (PDT) MIME-Version: 1.0 References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> In-Reply-To: From: Eric Rescorla Date: Thu, 18 Apr 2019 17:01:17 -0700 Message-ID: To: Fernando Gont Cc: =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000accd0e0586d6d31f" Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 00:02:00 -0000 --000000000000accd0e0586d6d31f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont wrote: > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > wrote: > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > > > >> > wrote: > > > > > > Folks, > > > > > > At the last secdispatch meeting I presented our I-D > > > draft-gont-predictable-numeric-ids. > > > > > > >From the meeting discussion, it would seem to me that there > > is support > > > for this work. > > > > > > It would also seem to me that part of this work is to be > > pursued in an > > > appropriate IRTF rg, while the update to RFC3552 > > > (draft-gont-numeric-ids-sec-considerations) should be pursued > > as an > > > AD-sponsored document. > > > > > > > > > I'm somewhat skeptical on an update to 3552; the proposed set of > > things > > > to be improved seems unclear. > > > > Can you please state what's unclear? > > > > > > I understand the list of things in your document. However, there have > > been proposals for a larger revision to 3552. > > There was an effort to revise RFC3552. It just didn't happen. Looks like > trying to boil the ocean wasn't the best idea. > Yes. > > It's a total of 9 pages. If you remove abstract, boilerplate, and > references, you end up with ~4 pages. In fact, the update (and > indispensable text) is that in Section 5, and boils down to: > > ---- cut here ---- > 5. Security and Privacy Requirements for Identifiers > > Protocol specifications that specify transient numeric identifiers > MUST: > > 1. Clearly specify the interoperability requirements for the > aforementioned identifiers. > > 2. Provide a security and privacy analysis of the aforementioned > identifiers. > > 3. Recommend an algorithm for generating the aforementioned > identifiers that mitigates security and privacy issues, such as > those discussed in [I-D.gont-predictable-numeric-ids]. > ---- cut here ---- > Eh, I think something like this would have been OK in 3552; I'm not sure that it's necessary to add at this point to the list of things that 3552 considers. > > That said, this document is *updating* RFC3552, rather than a > revision > > of RFC3552. Therefore, the content in this document wouldn't become > part > > of RFC3552, necessarily. > > > > > > Well, the semantics of "Updates" would be somewhat confusing here. > > Certainly I don't think that this document is something we need to > > transitively incorporate into 3552, but I care a lot less about the > > contents of this header than I do about whether 3552 should be updated > > to include this material. > > I do think RFC3552 should be updated as indicated (this stuff is general > enough to be covered there). > > That said, the high-order bit here is to do something to prevent the bad > history we have wrt numeric ids from repeating itself. > > If the whole point is that you'd like the "Updates: 3552 (if approved)" > header to be removed (along with references to "updating RFC3552"), > please say so. No, that's not my point. As I said, I don't think we should publish a new version of 3552 with this material or similar material in it. I don't much care one way or the other whether this document is published, and while I don't think marking it as updating 3552 is that helpful, I'm not going to die on that hill either. -Ekr --000000000000accd0e0586d6d31f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 4:40 PM Ferna= ndo Gont <fgont@si6networks.com= > wrote:
= On 19/4/19 01:09, Eric Rescorla wrote:
>
>
> On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont <fgont@si6networks.com
> <mailto:= fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 18/4/19 15:45, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont<= br> >=C2=A0 =C2=A0 =C2=A0<fgont@si6networks.com <mailto:fgont@si6networks.com>
>=C2=A0 =C2=A0 =C2=A0> <mailto:fgont@si6networks.com <mailto:fgont@si6networks.com>&= gt;> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Folks,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0At the last secdispatch mee= ting I presented our I-D
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0draft-gont-predictable-nume= ric-ids.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>From the meeting discus= sion, it would seem to me that there
>=C2=A0 =C2=A0 =C2=A0is support
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0for this work.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0It would also seem to me th= at part of this work is to be
>=C2=A0 =C2=A0 =C2=A0pursued in an
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0appropriate IRTF rg, while = the update to RFC3552
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(draft-gont-numeric-ids-sec= -considerations) should be pursued
>=C2=A0 =C2=A0 =C2=A0as an
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0AD-sponsored document.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I'm somewhat skeptical on an update to 355= 2; the proposed set of
>=C2=A0 =C2=A0 =C2=A0things
>=C2=A0 =C2=A0 =C2=A0> to be improved seems unclear.
>
>=C2=A0 =C2=A0 =C2=A0Can you please state what's unclear?
>
>
> I understand the list of things in your document. However, there have<= br> > been proposals for a larger revision to 3552.

There was an effort to revise RFC3552. It just didn't happen. Looks lik= e
trying to boil the ocean wasn't the best idea.
Yes.

=C2=A0

It's a total of 9 pages. If you remove abstract, boilerplate, and
references, you end up with ~4 pages. In fact, the update (and
indispensable text) is that in Section 5, and boils down to:

---- cut here ----
5.=C2=A0 Security and Privacy Requirements for Identifiers

=C2=A0 =C2=A0Protocol specifications that specify transient numeric identif= iers
=C2=A0 =C2=A0MUST:

=C2=A0 =C2=A01.=C2=A0 Clearly specify the interoperability requirements for= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0aforementioned identifiers.

=C2=A0 =C2=A02.=C2=A0 Provide a security and privacy analysis of the aforem= entioned
=C2=A0 =C2=A0 =C2=A0 =C2=A0identifiers.

=C2=A0 =C2=A03.=C2=A0 Recommend an algorithm for generating the aforementio= ned
=C2=A0 =C2=A0 =C2=A0 =C2=A0identifiers that mitigates security and privacy = issues, such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0those discussed in [I-D.gont-predictable-numeric= -ids].
---- cut here ----

Eh, I think somethin= g like this would have been OK in 3552; I'm not
sure that it&= #39;s necessary to add at this point to the list of things that
3= 552 considers.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0That said, this document is *updating* RFC3552, rat= her than a revision
>=C2=A0 =C2=A0 =C2=A0of RFC3552. Therefore, the content in this document= wouldn't become part
>=C2=A0 =C2=A0 =C2=A0of RFC3552, necessarily.
>
>
> Well, the semantics of "Updates" would be somewhat confusing= here.
> Certainly I don't think that this document is something we need to=
> transitively incorporate into 3552, but I care a lot less about the > contents of this header than I do about whether 3552 should be updated=
> to include this material.

I do think RFC3552 should be updated as indicated (this stuff is general enough to be covered there).

That said, the high-order bit here is to do something to prevent the bad history we have wrt numeric ids from repeating itself.

If the whole point is that you'd like the "Updates: 3552 (if appro= ved)"
header to be removed (along with references to "updating RFC3552"= ),
please say so.

No, that's not my point= . As I said, I don't think we should publish a new version
of= 3552 with this material or similar material in it. I don't much care o= ne way
or the other whether this document is published, and while= I don't think marking
it as updating 3552 is that helpful, I= 'm not going to die on that hill either.

-= Ekr
--000000000000accd0e0586d6d31f-- From nobody Thu Apr 18 17:32:22 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D651120233; Thu, 18 Apr 2019 17:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zc-ZlPJd_9uC; Thu, 18 Apr 2019 17:32:18 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9431200C3; Thu, 18 Apr 2019 17:32:18 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6788380DC6; Fri, 19 Apr 2019 02:32:15 +0200 (CEST) To: Eric Rescorla Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , pearg@irtf.org, secdispatch-chairs@ietf.org References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 02:17:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 00:32:21 -0000 On 19/4/19 02:01, Eric Rescorla wrote: > > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont > wrote: > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > >> wrote: > > > >     On 18/4/19 15:45, Eric Rescorla wrote: > >     > > >     > > >     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > >      > > > >     > > >>> wrote: [....] > It's a total of 9 pages. If you remove abstract, boilerplate, and > references, you end up with ~4 pages. In fact, the update (and > indispensable text) is that in Section 5, and boils down to: > > ---- cut here ---- > 5.  Security and Privacy Requirements for Identifiers > >    Protocol specifications that specify transient numeric identifiers >    MUST: > >    1.  Clearly specify the interoperability requirements for the >        aforementioned identifiers. > >    2.  Provide a security and privacy analysis of the aforementioned >        identifiers. > >    3.  Recommend an algorithm for generating the aforementioned >        identifiers that mitigates security and privacy issues, such as >        those discussed in [I-D.gont-predictable-numeric-ids]. > ---- cut here ---- > > > Eh, I think something like this would have been OK in 3552; I'm not > sure that it's necessary to add at this point to the list of things that > 3552 considers. Isn't https://tools.ietf.org/html/draft-gont-numeric-ids-history-04 enough of a justification to adding this? We keep producing specs with flawed IDs. Which take ages and a lot of effort an energy to fix. I'm kind of surprised that we're even discussing this. > >     That said, this document is *updating* RFC3552, rather than a > revision > >     of RFC3552. Therefore, the content in this document wouldn't > become part > >     of RFC3552, necessarily. > > > > > > Well, the semantics of "Updates" would be somewhat confusing here. > > Certainly I don't think that this document is something we need to > > transitively incorporate into 3552, but I care a lot less about the > > contents of this header than I do about whether 3552 should be updated > > to include this material. > > I do think RFC3552 should be updated as indicated (this stuff is general > enough to be covered there). > > That said, the high-order bit here is to do something to prevent the bad > history we have wrt numeric ids from repeating itself. > > If the whole point is that you'd like the "Updates: 3552 (if approved)" > header to be removed (along with references to "updating RFC3552"), > please say so. > > > No, that's not my point. As I said, I don't think we should publish a > new version > of 3552 with this material or similar material in it. We will not publish a new version of RFC3552 in the foreseeable future. That's a fact. So the issue you raise seems to boil down, in practice, whether we keep the "Updates: 3552 (if approved)" header and keep the two references to it (one in the abstract, and another in the Sec Cons). If that's the show-stopper, we don't mind removing that. The high-order bit here is to continue repeating the history of flawed IDs (there are active I-Ds that keep doing a bad job at this). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 18 18:25:24 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7B120183; Thu, 18 Apr 2019 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPaUQjnVKH7M; Thu, 18 Apr 2019 18:25:12 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9BFAB12003F; Thu, 18 Apr 2019 18:25:12 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J1P7vT014596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2019 21:25:09 -0400 Date: Thu, 18 Apr 2019 20:25:07 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: Fernando Gont , pearg@irtf.org, IETF SecDispatch , =?iso-8859-1?Q?Iv=E1n_Arce_=28Quarkslab=29?= , secdispatch-chairs@ietf.org Message-ID: <20190419012507.GB95327@kduck.mit.edu> References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 01:25:15 -0000 On Thu, Apr 18, 2019 at 05:01:17PM -0700, Eric Rescorla wrote: > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont wrote: > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > wrote: > > > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > > > > > >> > > wrote: > > > > > > > > Folks, > > > > > > > > At the last secdispatch meeting I presented our I-D > > > > draft-gont-predictable-numeric-ids. > > > > > > > > >From the meeting discussion, it would seem to me that there > > > is support > > > > for this work. > > > > > > > > It would also seem to me that part of this work is to be > > > pursued in an > > > > appropriate IRTF rg, while the update to RFC3552 > > > > (draft-gont-numeric-ids-sec-considerations) should be pursued > > > as an > > > > AD-sponsored document. > > > > > > > > > > > > I'm somewhat skeptical on an update to 3552; the proposed set of > > > things > > > > to be improved seems unclear. > > > > > > Can you please state what's unclear? > > > > > > > > > I understand the list of things in your document. However, there have > > > been proposals for a larger revision to 3552. > > > > There was an effort to revise RFC3552. It just didn't happen. Looks like > > trying to boil the ocean wasn't the best idea. > > > > Yes. > > > > > > > It's a total of 9 pages. If you remove abstract, boilerplate, and > > references, you end up with ~4 pages. In fact, the update (and > > indispensable text) is that in Section 5, and boils down to: > > > > ---- cut here ---- > > 5. Security and Privacy Requirements for Identifiers > > > > Protocol specifications that specify transient numeric identifiers > > MUST: > > > > 1. Clearly specify the interoperability requirements for the > > aforementioned identifiers. > > > > 2. Provide a security and privacy analysis of the aforementioned > > identifiers. > > > > 3. Recommend an algorithm for generating the aforementioned > > identifiers that mitigates security and privacy issues, such as > > those discussed in [I-D.gont-predictable-numeric-ids]. > > ---- cut here ---- > > > > Eh, I think something like this would have been OK in 3552; I'm not > sure that it's necessary to add at this point to the list of things that > 3552 considers. > > > > > > That said, this document is *updating* RFC3552, rather than a > > revision > > > of RFC3552. Therefore, the content in this document wouldn't become > > part > > > of RFC3552, necessarily. > > > > > > > > > Well, the semantics of "Updates" would be somewhat confusing here. > > > Certainly I don't think that this document is something we need to > > > transitively incorporate into 3552, but I care a lot less about the > > > contents of this header than I do about whether 3552 should be updated > > > to include this material. > > > > I do think RFC3552 should be updated as indicated (this stuff is general > > enough to be covered there). > > > > That said, the high-order bit here is to do something to prevent the bad > > history we have wrt numeric ids from repeating itself. > > > > If the whole point is that you'd like the "Updates: 3552 (if approved)" > > header to be removed (along with references to "updating RFC3552"), > > please say so. > > > No, that's not my point. As I said, I don't think we should publish a new > version > of 3552 with this material or similar material in it. I don't much care one > way > or the other whether this document is published, and while I don't think > marking > it as updating 3552 is that helpful, I'm not going to die on that hill > either. Do you care to state an opinion on "Updates: 3552" vs. an additional document in BCP 72 (vs. both or none)? Thanks, Ben From nobody Thu Apr 18 21:25:37 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A472120086 for ; Thu, 18 Apr 2019 21:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucz39eynVWa4 for ; Thu, 18 Apr 2019 21:25:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A638512000E for ; Thu, 18 Apr 2019 21:25:34 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J4PNi0032035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 00:25:25 -0400 Date: Thu, 18 Apr 2019 23:25:23 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: "Owen Friel (ofriel)" , =?iso-8859-1?Q?G=F6ran?= Selander , Richard Barnes , Michael Richardson , Carsten Bormann , "secdispatch@ietf.org" , Martin Thomson Message-ID: <20190419042522.GF95327@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 04:25:36 -0000 Hi Hannes, On Tue, Apr 16, 2019 at 07:26:02AM +0000, Hannes Tschofenig wrote: > > Richard Barnes > wrote: > > > I'd like to push back on this point. It may be that EDHOC has been around for > > > a while and been well-socialized with the IoT crowd, but it is clearly > > > deficient in several other types of maturity, e.g., robustness of formal > > > analyses and state of implementations (AFAICT). > > I would like to point out that initially the work on EDHOC was intentionally not positioned as a TLS replacement (or even competitor). > For years I was told that it is supposed to be used in addition to and on top of TLS. > > Fast forward a few years the story is very different now. I'm not sure that this line of discussion is going to be very productive. Plans can change over time, and of course a technology that is inspired for one use case can take off and become a key part of designs all over the place (consider, perhaps, the wild success of the DNS, or as a less extreme example the wide variety of things people want to do with BRSKI). The specific technical issue in front of us seems to be a claim that there is a scenario with wide deployment applicability where the (mostly size) message constraints are such that stock TLS is not applicable and an alternative AKE is needed. This is not surprising given that stock TLS has not really been designed to skimp on the byte count of message encoding, though of course we can revisit that aspect of TLS in some ways. I would welcome technical reasoning that, e.g., the indicated scenario(s) do not actually have wide deployment applicability, or that stock TLS is in fact usable in these scenarios, but the history of EDHOC's origins does not really seem relevant to the technical issues. Thanks, Ben From nobody Thu Apr 18 21:54:12 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024241202B2 for ; Thu, 18 Apr 2019 21:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVag8hUDNF3E for ; Thu, 18 Apr 2019 21:54:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CE9EF120106 for ; Thu, 18 Apr 2019 21:53:59 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J4rrfb006038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 00:53:55 -0400 Date: Thu, 18 Apr 2019 23:53:53 -0500 From: Benjamin Kaduk To: Hannes Tschofenig Cc: "secdispatch@ietf.org" Message-ID: <20190419045353.GG95327@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] Regarding the EDHOC IETF Developments X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 04:54:10 -0000 Hi Hannes, On Sun, Apr 14, 2019 at 12:34:46PM +0000, Hannes Tschofenig wrote: > Hi all, > > I was negatively surprised about the conclusions the area directors have taken with regard to the proposed work on EDHOC. I'm not sure that you think the conclusions we reached are the conclusions that I think we reached, so let me try to say a bit more about my perspective of where things stand. > I have therefore used this as an opportunity to reach out to my co-workers working on IoT deployments and our embedded implementations to collect their feedback. They have not run into performance problems with the use of DTLS & TLS 1.2 today (and our technology is used in lots of IoT environments). Our Mbed teams are continuously working on enhancements, including RAM and codesize improvements, for the security stacks and also for the IoT operating systems. Things work fine today even though some of the newer IETF work in the security area has not yet been utilized. Embedded system development takes time. You and your colleagues' work on (D)TLS, mbed TLS, and such are greatly appreciated. But I hope you can sympathize with the statement that "there is IoT, and then there is IoT" -- the term means different things to different people. So what Roman and I tried to do with all the information that came out of the interim was to pull togther some of the concrete scope and requirements information that had been presented. In particular, we tried to give specific references to concrete scenarios like the 6TiSCH multihop join scenario (which seems to impose a fairly sharp limit on the frame count) and the LoRaWAN duty cycle constraints. We've already seen some follow-up questioning whether these constraints apply in all the stated scenarios, and I welcome the greater clarity that those discussions are providing. > The recent work on cTLS gives me the impression that performance optimization can be gained incrementally. That's very good news for those companies who have made several years of investment in those stacks. With our commitment to build a high-quality embedded TLS/DTLS tack (along with the crypto) we are obviously interested to see further work in that direction. I have started with a prototype implementation of the cTLS draft. It was a simple exercise without many code changes. I don't think anyone is arguing that something like cTLS is not worth working on. But that's not really topical to the question of what to do for the specific concrete scenarios that were presented at the interim, especially when we are getting requests from other WGs to get something "good enough" out quickly instead of delaying indefinitely to get closer to perfection. > I understand that nobody wants to hear that they shouldn't standardize their favourite solution. No IESG member likes to convey that message because they would like to get re-elected. Working group chairs obviously don't like to communicate such a message either. In the end, we have lots of solutions in the hope that the "market will figure it out". Just look at how many solutions for communication security we have (see Section 4.2 of draft-irtf-t2trg-iot-seccons-16) or how many different ways to provision credentials (see draft-sarikaya-t2trg-sbootstrapping-06 and we are adding more -- https://bit.ly/2v4p7rn) there are. The IETF has become really efficient in publishing specs. That's great. It is a pity that the embedded community is not that fast to deploy them. I'm happy to tell document authors that their document is unlikely to get published in the case where it doesn't solve a real problem with real use case. The numbers we've seen presented so far haven't really convinced me that this is the case for the concrete scenarios that were presented at the interim, though. (But there are still a couple related threads ongoing, I suppose, so we can see how they progress.) -Ben > Normally, we do not care if someone proposes yet another solution. Unfortunately, for IoT-related stuff we spend a lot of time explaining why certain solutions are neither available in IoT operating systems, why they are not doing what they claim to do, or why the problems are actually somewhere else. We are worried about the collateral damage that results from standardizing EDHOC. > > Ciao > Hannes > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Thu Apr 18 22:23:31 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51AB120072 for ; Thu, 18 Apr 2019 22:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er3vySPpS2we for ; Thu, 18 Apr 2019 22:23:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7FD32120020 for ; Thu, 18 Apr 2019 22:23:28 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J5NOgr012215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 01:23:26 -0400 Date: Fri, 19 Apr 2019 00:23:24 -0500 From: Benjamin Kaduk To: "Blomqvist, Peter" Cc: Richard Barnes , "secdispatch@ietf.org" Message-ID: <20190419052324.GB51586@kduck.mit.edu> References: <1554794627589.50834@sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1554794627589.50834@sony.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 05:23:31 -0000 On Tue, Apr 09, 2019 at 07:23:47AM +0000, Blomqvist, Peter wrote: > Hi Richard, > > > Code footprint is not extremely constrained, typically Cortex M4 or similar. > > Battery however is constrained. Also data transport. > > > Optimistic marketing state that devices now can run 10 years on coin cells - adding security to such a battery budget is problematic to say the least. At one point I looked at the numbers in https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf and tried to do some ballpark numbers on total power consumption for key exchange over the lifetime of the device. I don't have a great handle on whether, say, 1000 mAh is plausible for the usable energy in a coin cell, but IIRC at one rekeying event per month and some similar assumptions I could get the lifetime energy consumption to be around 0.5% for the AKE. Hopefully someone could replicate those numbers (I don't remember where I put my notes) and comment on how much slack there is in the power budget for this sort of thing. -Ben From nobody Thu Apr 18 22:45:09 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616B120222 for ; Thu, 18 Apr 2019 22:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpIm_Az-bbPZ for ; Thu, 18 Apr 2019 22:45:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6AD431201B6 for ; Thu, 18 Apr 2019 22:45:01 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J5iwPR016685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 01:45:00 -0400 Date: Fri, 19 Apr 2019 00:44:58 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: secdispatch@ietf.org Message-ID: <20190419054457.GC51586@kduck.mit.edu> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 05:45:07 -0000 Hi Martin, Sorry for the slow response. Roman and I were both separately out of commission for several days (non-overlapping, per Murphy's law), and so it was hard to sync up. On Mon, Apr 08, 2019 at 07:17:14PM -0400, Martin Thomson wrote: > Hi Roman, Ben, > > I’m a little surprised to see that your conclusion from the meeting we > had was so clear. The summary shared at the end of the meeting > highlighted the need to clarify the scope and nature of the requirements. We agree that there was a need to clarify the scope and nature of the requirements coming out of the virtual interim meeting.  However, we felt that many of the open questions were ultimately clarified in follow-on discussion and through detailed review of the materials that were prepared, but not adequately presented due to time constraints. Thus, we tried to put in a lot of specific references to actual concrete scenarios, data, and use cases. The summary below leveraged your early insight [1] prior to the virtual interim meeting to use the four new work questions to organize what have been discussed, presented and prepared, in a familiar format. > There has been some discussion on the list on this subject, but I haven’t > seen anything that indicates consensus around the problem statement. > We view the problem statement as essentially your question #1, "what is the problem we are faced with?" During the meeting and in follow-up discussions, we heard a diversity of opinions but no push back that (per the summary below) "the community needs an AKE that is 'lightweight' and enables forward security for constrained environments". > The framing of this summary seems to imply that the goal is to work on > EDHOC. That seems premature. There seems to be agreement that the > authenticated key exchange (AKE) protocols we have are inefficient in > ways that affect these deployments. We concur that there is agreement that current AKE protocols are inefficient in certain deployments.  As noted above, this is why we feel that question #1 has been answered. > That doesn’t naturally imply that EDHOC is a solution, only that there is > a need to have an efficient AKE protocol. Correct.  For this reason, the summary below walked through the four new-work questions and evaluated the published solutions available at the time. > “As cheap as possible” is not a problem statement that is sufficiently precise to be acted upon. For example, the analysis for LoRaWAN seemed to support the conclusion that ANY key exchange protocol would fail badly, no matter how small, fast, or efficient. For deployments with capabilities that might support an AKE, we have no grounds for determining whether 5nJ or 1 octet difference is acceptable or not. Concrete objectives - ideally targets with numbers - are needed if we’re to assess solutions. We believe that such specificity is the essence of questions #2 and #3, and again, we tried to use specific references to material that has already been presented, to shape our picture of what the answers to those questions are. We agree that "as cheap as possible" is not clear.  For these reason, question #2 outlines slightly more specific metrics for the individual protocols (but not down to specific byte counts).  In the case of certain active IETF work which would use this AKE, specifically 6Tisch, it has been confirmed that we can get a usable key exchange mechanism even though the overhead and the constraint of fitting into a single MTU limits the hop count over which the key exchange is performed. > Even assuming that requirements are settled, I believe that there are considerations that go beyond the narrow definition of the problem statement. In the recent review of the T2TRG, I was reminded of their goal: > > > The Thing-to-Thing Research Group (T2TRG) will investigate open research issues in turning a true "Internet of Things" into reality, an Internet where low-resource nodes ("things", "constrained nodes") can communicate among themselves and with the wider Internet, in order to partake in permissionless innovation. > > Though a little wordy, I think that this is a fine goal to keep in mind. Deciding to create a working group specifically for EDHOC makes a determination directly in opposition to this goal. We’ve made similar choices for application protocols like CoAP. For CoAP, the agreed fix was gateways and proxies. For a security protocol, that is not an option if you value end-to-end security. We can't disagree with the vision of suggested by T2TRG.  However, how this vision reframes the answers summarized below to the scoping questions isn't clear. Are we supposed to not even try to solve problems in front of IETF WGs because they don't fit into a grand vision? It seems we should hope to find engineering solutions, complete with the engineering compromises that entails. Regards, Ben and Roman [1] https://mailarchive.ietf.org/arch/msg/secdispatch/7G3vjVvoYyWXUB3qtqhLqd90AXs > > On Thu, Mar 28, 2019, at 21:33, Roman Danyliw wrote: > > Hi! > > > > We have observed the continued discussion and interest in the topics > > discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. > > Our assessment of the current state of this discuss and as well as > > proposed next steps are below. > > > > Regards, > > Roman and Ben > > > > [1] > > https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk > > > > ==[ Summary of ADs ]== > > EDHOC Summary > > > > -----[ 1. What is the problem we are faced with? > > > > The community needs an AKE that is 'lightweight' (per slide #3 of [2]) > > and enables forward security for constrained environments using OSCORE > > [13]. 'Lightweight' refers to: > > > > ** resource consumption, measured by bytes on the wire, wall-clock time > > to complete (i.e., the initial latency added to application protocols > > by the AKE), or power (per slide #12 of [2]) > > ** the amount of new code required on end systems which already have an > > OSCORE stack [4] > > > > -----[ 2. Is the problem understood and narrowly scoped? > > > > Use with OSCORE implicitly assumes that this AKE would support: > > ** transport over CoAP, and > > ** COSE algorithms > > > > The specific constrained environments that we are considering use > > NB-IoT, 6TiSCH, and LoRaWAN. The desire is to optimize the AKE to be > > 'as [small] ... as reasonably achievable' (per [3]) in these > > environments. > > > > ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has > > already identified the need to "secur[e] the join process and mak[e] > > that fit within the constraints of high latency, low throughput and > > small frame sizes that characterize IEEE802.15.4 TSCH." [12]. > > ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG > > charter has identified the need to improve the transport capabilities > > of LPWA networks such as NB-IoT and LoRa whose "common traits include > > ... frame sizes ... [on] the order of tens of bytes transmitted a few > > times per day at ultra-low speeds" [16]. This indicates IETF interest > > in supporting these radio environments, though no security-specific > > requirements are included in the charter. > > > > It may be necessary to evaluate options that make different trade-offs > > across a number of dimensions. > > > > ** Per 'bytes on the wire', it is desirable for these AKE messages to > > fit into the MTU size of these protocols; and if not possible, within > > as few frames as possible. Note that using multiple MTUs can have > > significant costs in terms of time and power (listed below). For 6TiSCH > > specifically, as a time-sliced network, this metric (or rather, the > > quantization into frame count) is particularly noteworthy, since more > > frames contribute to congestion for spectrum (and concomitant error > > rates) in a non-linear way, especially in scenarios when large numbers > > of independent nodes are attempting to execute an AKE to join a network. > > > > ** Per 'time', it is desirable for the AKE message exchange(s) to > > complete in a reasonable amount of time, both for a single uncongested > > exchange and when multiple exchanges are running in an interleaved > > fashion. This latency may not be a linear function depending on > > congestion and the specific radio technology used. For LoRaWAN, which > > is legally required to use a 1% (or smaller) duty cycle, a payload > > split into two fragments instead of one increases the time to complete > > the sending of this payload by 10,000% (per slide #10 of [2]). > > > > ** Per 'power', it is desirable for the transmission of AKE messages > > and crypto to draw as little power as possible The best mechanism for > > doing so differs across radio technologies. For example, NB-IoT uses > > licensed spectrum and thus can transmit at higher power to improve > > coverage, making the transmitted byte count relatively more important > > than for other radio technologies. In other cases, the radio > > transmitter will be active for a full MTU frame regardless of how much > > of the frame is occupied by message content, which makes the byte count > > less sensitive for the power consumption. Increased power consumption > > is unavoidable in poor network conditions, such as most wide-area > > settings including LoRaWAN. > > > > ** Per 'new code', it is desirable to introduce as little new code as > > possible onto OSCORE-enabled devices to support this new AKE. These > > devices have on the order of 10s of kB of memory and 100s of kB of > > storage on which an embedded OS; a COAP stack; CORE and AKE libraries; > > and target applications would run. It is expected that the majority of > > this space is available for actual application logic, as opposed to > > the support libraries. > > > > A key question to answer is whether any new solution will reduce these > > properties to a sufficient extent to merit investment. > > > > -----[ 3. Do we believe it is possible to engineer a solution? > > > > EDHOC [1] appears to be an existence proof that it is possible to > > produce an AKE that meaningfully reduces the costs across at least two > > dimensions identified in question #1 and 2 (bytes and time). > > > > EDHOC appears to favorably outperform TLS/CoAP, the current technology, > > relative to these dimensions. > > > > ** Per 'bytes on the wire', MTU sizes and their alignment to the size > > of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and > > in [5]. Additional details for 6TiSCH in particular can be found in > > slide 36-37 of [2]. > > > > ** Per 'time', the latency due to back-off time estimates with EDHOC > > vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2] > > > > ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP using > > NB-IoT can be found in slide #35 of [2] > > > > ** Per 'new code', being able to reuse primitives from the existing > > COSE stack is expected to benefit the code size for EDHOC, but no hard > > data is yet available for comparison. > > > > Exploratory work with cTLS [10] and femtoTLS [11] has suggested that > > certain optimizations used in EDHOC can also be applied to a > > TLS/CoAP-variant. How this impacts the original assumptions and > > security analysis for (D)TLS is unknown. > > > > -----[ 4. Is this particular proposal a good basis for working on? > > > > EDHOC shows gains in defining an AKE with forward secrecy that is > > 'reasonably small[er]' than the baseline of (D)TLS. Specifically, it > > appears that EDHOC would enable: > > ** for 6TiSCH, a more efficient network join operation, with network > > join traffic fitting in one frame per flight (that is, the optimal > > possible behavior) in up to a 5-hop network [17] > > ** for LoRaWAN, an AKE with forward secrecy that avoids the > > unacceptable backoff-induced latency > > > > A limited interop was performed on draft-selander-ace-cose-ecdhe-05 > > (EDHOC) at IETF 98 between [14] and [15]. Despite the inherent > > challenges of producing a new AKE that is secure, there is reason to > > have confidence in the security claims made by EDHOC -- the security > > properties of -08 were formally verified by [8][9]. Identified issues > > from this formal analysis [8] were addressed in -11. The CFRG crypto > > review panel conducted two reviews [6][7]. These reviews confirmed > > that the security claims are reasonable, attested that the identified > > issues found in the formal analysis [8] were fixed, and provided > > additional recommendations. > > > > Re-encoding of the TLS handshake as suggested by cTLS [10] may be > > possible. However, as of yet, cTLS is an incomplete specification, > > cTLS has no formal security analysis, and is technically a new protocol. > > > > -----[ Conclusion > > > > There appears to be an understood and scoped problem that is feasible > > to engineer. Among the available starting points to address the > > problem defined in question #1, EDHOC presents a viable choice. > > > > Chartering a narrowly scoped, short-lived WG in this space with EDHOC > > as a starting point seems to be an attractive path forward, but we > > would like to receive community feedback on the degree of support for > > this approach. > > > > -----[ References > > [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt > > [2] > > https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf > > [3] > > https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE > > [4] > > https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0 > > [5] > > https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k > > [6] > > https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8 > > [7] > > https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ > > [8] https://alessandrobruni.name/papers/18-edhoc.pdf > > [9] https://github.com/theisgroenbech/edhoc-proverif > > [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 > > [11] https://github.com/bifurcation/mint/compare/ftls > > [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/ > > [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ > > [14] https://github.com/alexkrontiris/EDHOC-C > > [15] https://github.com/jimsch/EDHOC-csharp > > [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/ > > [17] > > https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join > > > > ==[ End ]== > > > > _______________________________________________ > > Secdispatch mailing list > > Secdispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/secdispatch > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Thu Apr 18 22:50:47 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D666D120283 for ; Thu, 18 Apr 2019 22:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcADmVP_5PvY for ; Thu, 18 Apr 2019 22:50:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2AFD512011A for ; Thu, 18 Apr 2019 22:50:41 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3J5oZdT017859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 01:50:37 -0400 Date: Fri, 19 Apr 2019 00:50:35 -0500 From: Benjamin Kaduk To: =?iso-8859-1?Q?G=F6ran?= Selander Cc: "secdispatch@ietf.org" , Martin Thomson Message-ID: <20190419055035.GD51586@kduck.mit.edu> References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 05:50:46 -0000 On Tue, Apr 09, 2019 at 11:57:52AM +0000, Göran Selander wrote: > Hi Martin, > > Some comments inline. > > On 2019-04-09, 01:18, "Secdispatch on behalf of Martin Thomson" wrote: > > Hi Roman, Ben, > > I’m a little surprised to see that your conclusion from the meeting we had was so clear. The summary shared at the end of the meeting highlighted the need to clarify the scope and nature of the requirements. There has been some discussion on the list on this subject, but I haven’t seen anything that indicates consensus around the problem statement. > > [GS] There seems to be consensus on the summary provided by the Security ADs, which includes the problem statement. Well, I don't think we really have had a chance to gather great data about whether there is consensus around the summary that Roman and I collated. But, as noted in my message to Martin just now, we aren't really seeing opposition to providing a lightweight AKE for usage in constrained scenarios, such as those that were presented at the interim. > The framing of this summary seems to imply that the goal is to work on EDHOC. That seems premature. There seems to be agreement that the authenticated key exchange (AKE) protocols we have are inefficient in ways that affect these deployments. That doesn’t naturally imply that EDHOC is a solution, only that there is a need to have an efficient AKE protocol. > > [GS] There is no competing solution to the problem statement. As been witnessed, people have waited for years for this to progress. Therefore I don't see anything premature with assuming EDHOC to be a starting point for the WG. I think some people are trying to propose competing solutions (in various forms) as part of this thread. Per IETF tradition, of course, such things are easier to evaluate when in I-D form than just sketched out in emails. -Ben > “As cheap as possible” is not a problem statement that is sufficiently precise to be acted upon. For example, the analysis for LoRaWAN seemed to support the conclusion that ANY key exchange protocol would fail badly, no matter how small, fast, or efficient. For deployments with capabilities that might support an AKE, we have no grounds for determining whether 5nJ or 1 octet difference is acceptable or not. Concrete objectives - ideally targets with numbers - are needed if we’re to assess solutions. > > [GS] Concrete targets with numbers have been presented, for example here: > https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU > > Even assuming that requirements are settled, I believe that there are considerations that go beyond the narrow definition of the problem statement. In the recent review of the T2TRG, I was reminded of their goal: > > > The Thing-to-Thing Research Group (T2TRG) will investigate open research issues in turning a true "Internet of Things" into reality, an Internet where low-resource nodes ("things", "constrained nodes") can communicate among themselves and with the wider Internet, in order to partake in permissionless innovation. > > Though a little wordy, I think that this is a fine goal to keep in mind. Deciding to create a working group specifically for EDHOC makes a determination directly in opposition to this goal. We’ve made similar choices for application protocols like CoAP. For CoAP, the agreed fix was gateways and proxies. For a security protocol, that is not an option if you value end-to-end security. > > [GS] A lightweight AKE on application layer, which this specific WG is proposed to work on, is actually a missing enabler for constrained nodes to "communicate among themselves and with the wider Internet". Indeed, if the security protocol is too heavy or needs to terminate in a gateway due to change of transport etc., then end-to-end secure communication between the endpoints will not take place, thus preventing "to partake in permissionless innovation". > > Göran > > > > Cheers, > Martin > > On Thu, Mar 28, 2019, at 21:33, Roman Danyliw wrote: > > Hi! > > > > We have observed the continued discussion and interest in the topics > > discussed at the March 2019 Virtual Interim Secdispatch meeting [1]. > > Our assessment of the current state of this discuss and as well as > > proposed next steps are below. > > > > Regards, > > Roman and Ben > > > > [1] > > https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk > > > > ==[ Summary of ADs ]== > > EDHOC Summary > > > > -----[ 1. What is the problem we are faced with? > > > > The community needs an AKE that is 'lightweight' (per slide #3 of [2]) > > and enables forward security for constrained environments using OSCORE > > [13]. 'Lightweight' refers to: > > > > ** resource consumption, measured by bytes on the wire, wall-clock time > > to complete (i.e., the initial latency added to application protocols > > by the AKE), or power (per slide #12 of [2]) > > ** the amount of new code required on end systems which already have an > > OSCORE stack [4] > > > > -----[ 2. Is the problem understood and narrowly scoped? > > > > Use with OSCORE implicitly assumes that this AKE would support: > > ** transport over CoAP, and > > ** COSE algorithms > > > > The specific constrained environments that we are considering use > > NB-IoT, 6TiSCH, and LoRaWAN. The desire is to optimize the AKE to be > > 'as [small] ... as reasonably achievable' (per [3]) in these > > environments. > > > > ** With respect to 6TiSCH, IETF consensus on the 6TiSCH WG charter has > > already identified the need to "secur[e] the join process and mak[e] > > that fit within the constraints of high latency, low throughput and > > small frame sizes that characterize IEEE802.15.4 TSCH." [12]. > > ** With respect to NB-IoT and LoRaWAN, IETF consensus on the LPWAN WG > > charter has identified the need to improve the transport capabilities > > of LPWA networks such as NB-IoT and LoRa whose "common traits include > > ... frame sizes ... [on] the order of tens of bytes transmitted a few > > times per day at ultra-low speeds" [16]. This indicates IETF interest > > in supporting these radio environments, though no security-specific > > requirements are included in the charter. > > > > It may be necessary to evaluate options that make different trade-offs > > across a number of dimensions. > > > > ** Per 'bytes on the wire', it is desirable for these AKE messages to > > fit into the MTU size of these protocols; and if not possible, within > > as few frames as possible. Note that using multiple MTUs can have > > significant costs in terms of time and power (listed below). For 6TiSCH > > specifically, as a time-sliced network, this metric (or rather, the > > quantization into frame count) is particularly noteworthy, since more > > frames contribute to congestion for spectrum (and concomitant error > > rates) in a non-linear way, especially in scenarios when large numbers > > of independent nodes are attempting to execute an AKE to join a network. > > > > ** Per 'time', it is desirable for the AKE message exchange(s) to > > complete in a reasonable amount of time, both for a single uncongested > > exchange and when multiple exchanges are running in an interleaved > > fashion. This latency may not be a linear function depending on > > congestion and the specific radio technology used. For LoRaWAN, which > > is legally required to use a 1% (or smaller) duty cycle, a payload > > split into two fragments instead of one increases the time to complete > > the sending of this payload by 10,000% (per slide #10 of [2]). > > > > ** Per 'power', it is desirable for the transmission of AKE messages > > and crypto to draw as little power as possible The best mechanism for > > doing so differs across radio technologies. For example, NB-IoT uses > > licensed spectrum and thus can transmit at higher power to improve > > coverage, making the transmitted byte count relatively more important > > than for other radio technologies. In other cases, the radio > > transmitter will be active for a full MTU frame regardless of how much > > of the frame is occupied by message content, which makes the byte count > > less sensitive for the power consumption. Increased power consumption > > is unavoidable in poor network conditions, such as most wide-area > > settings including LoRaWAN. > > > > ** Per 'new code', it is desirable to introduce as little new code as > > possible onto OSCORE-enabled devices to support this new AKE. These > > devices have on the order of 10s of kB of memory and 100s of kB of > > storage on which an embedded OS; a COAP stack; CORE and AKE libraries; > > and target applications would run. It is expected that the majority of > > this space is available for actual application logic, as opposed to > > the support libraries. > > > > A key question to answer is whether any new solution will reduce these > > properties to a sufficient extent to merit investment. > > > > -----[ 3. Do we believe it is possible to engineer a solution? > > > > EDHOC [1] appears to be an existence proof that it is possible to > > produce an AKE that meaningfully reduces the costs across at least two > > dimensions identified in question #1 and 2 (bytes and time). > > > > EDHOC appears to favorably outperform TLS/CoAP, the current technology, > > relative to these dimensions. > > > > ** Per 'bytes on the wire', MTU sizes and their alignment to the size > > of messages of EDHOC vs. TLS/CoAP can be found in slide #33 of [2], and > > in [5]. Additional details for 6TiSCH in particular can be found in > > slide 36-37 of [2]. > > > > ** Per 'time', the latency due to back-off time estimates with EDHOC > > vs. TLS/CoAP using LoRaWAN can be found in slide #39 of [2] > > > > ** Per 'power', estimates of the power usage of EDHOC vs TLS/CoAP using > > NB-IoT can be found in slide #35 of [2] > > > > ** Per 'new code', being able to reuse primitives from the existing > > COSE stack is expected to benefit the code size for EDHOC, but no hard > > data is yet available for comparison. > > > > Exploratory work with cTLS [10] and femtoTLS [11] has suggested that > > certain optimizations used in EDHOC can also be applied to a > > TLS/CoAP-variant. How this impacts the original assumptions and > > security analysis for (D)TLS is unknown. > > > > -----[ 4. Is this particular proposal a good basis for working on? > > > > EDHOC shows gains in defining an AKE with forward secrecy that is > > 'reasonably small[er]' than the baseline of (D)TLS. Specifically, it > > appears that EDHOC would enable: > > ** for 6TiSCH, a more efficient network join operation, with network > > join traffic fitting in one frame per flight (that is, the optimal > > possible behavior) in up to a 5-hop network [17] > > ** for LoRaWAN, an AKE with forward secrecy that avoids the > > unacceptable backoff-induced latency > > > > A limited interop was performed on draft-selander-ace-cose-ecdhe-05 > > (EDHOC) at IETF 98 between [14] and [15]. Despite the inherent > > challenges of producing a new AKE that is secure, there is reason to > > have confidence in the security claims made by EDHOC -- the security > > properties of -08 were formally verified by [8][9]. Identified issues > > from this formal analysis [8] were addressed in -11. The CFRG crypto > > review panel conducted two reviews [6][7]. These reviews confirmed > > that the security claims are reasonable, attested that the identified > > issues found in the formal analysis [8] were fixed, and provided > > additional recommendations. > > > > Re-encoding of the TLS handshake as suggested by cTLS [10] may be > > possible. However, as of yet, cTLS is an incomplete specification, > > cTLS has no formal security analysis, and is technically a new protocol. > > > > -----[ Conclusion > > > > There appears to be an understood and scoped problem that is feasible > > to engineer. Among the available starting points to address the > > problem defined in question #1, EDHOC presents a viable choice. > > > > Chartering a narrowly scoped, short-lived WG in this space with EDHOC > > as a starting point seems to be an attractive path forward, but we > > would like to receive community feedback on the degree of support for > > this approach. > > > > -----[ References > > [1] https://www.ietf.org/id/draft-selander-ace-cose-ecdhe-13.txt > > [2] > > https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf > > [3] > > https://mailarchive.ietf.org/arch/msg/secdispatch/-GPqswnS-DRvrAKsPbdoes4Y4lE > > [4] > > https://mailarchive.ietf.org/arch/msg/secdispatch/rJqvstLHo7aLfu-ODril-wIVn_0 > > [5] > > https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k > > [6] > > https://mailarchive.ietf.org/arch/msg/cfrg/6WN2C2RYGTIAInE2jIUco6L9pO8 > > [7] > > https://mailarchive.ietf.org/arch/msg/cfrg/2OY2om1FjhNNBmUzwYJroHv7eWQ > > [8] https://alessandrobruni.name/papers/18-edhoc.pdf > > [9] https://github.com/theisgroenbech/edhoc-proverif > > [10] https://tools.ietf.org/html/draft-rescorla-tls-ctls-01 > > [11] https://github.com/bifurcation/mint/compare/ftls > > [12] https://datatracker.ietf.org/doc/charter-ietf-6tisch/ > > [13] https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ > > [14] https://github.com/alexkrontiris/EDHOC-C > > [15] https://github.com/jimsch/EDHOC-csharp > > [16] https://datatracker.ietf.org/doc/charter-ietf-lpwan/ > > [17] > > https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join > > > > ==[ End ]== > > > > _______________________________________________ > > Secdispatch mailing list > > Secdispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/secdispatch > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Fri Apr 19 00:08:01 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABDC1202BB; Fri, 19 Apr 2019 00:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 2hJvqhJgMcGX; Fri, 19 Apr 2019 00:07:48 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27F31202B8; Fri, 19 Apr 2019 00:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5KRDbnN9XVbXhrMn5vempWfD6gUIwpAHSAfbQNOc2HA=; b=fXs6ifg0NuFaqqKWFmTkGjN9dt8ldnbaEo3jkAU1ujxB7M6nvigIT4+DpYuc1Q3yogBt+5doxaHvF+3aFcH0OjiSaUgM45wBsXSN0467t4+rgAsG2m6LC87nCLSHPKZ04+W/dIiUgiG1R9XP13oVj1VMKosMHeEiiK4psDNY9mE= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4008.eurprd08.prod.outlook.com (20.179.0.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Fri, 19 Apr 2019 07:07:44 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Fri, 19 Apr 2019 07:07:44 +0000 From: Hannes Tschofenig To: Fernando Gont , Eric Rescorla CC: =?iso-8859-1?Q?Iv=E1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , "pearg@irtf.org" , "secdispatch-chairs@ietf.org" Thread-Topic: [Secdispatch] Numeric IDs: Update to RFC3552 Thread-Index: AQHU9DPSC6AaW/J3sUCYhloaFRIZ4KZB8XkAgACHeoCAAJgRgA== Date: Fri, 19 Apr 2019 07:07:44 +0000 Message-ID: References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ae77cc7-b501-401b-1751-08d6c495b8af x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4008; x-ms-traffictypediagnostic: AM6PR08MB4008: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(136003)(366004)(376002)(189003)(199004)(40434004)(13464003)(476003)(97736004)(4326008)(33656002)(74316002)(66066001)(2906002)(7736002)(25786009)(3846002)(8936002)(71200400001)(71190400001)(6116002)(52536014)(66476007)(68736007)(66556008)(72206003)(81166006)(305945005)(11346002)(446003)(14444005)(81156014)(486006)(5660300002)(478600001)(5024004)(966005)(6246003)(229853002)(55016002)(53936002)(186003)(26005)(66946007)(73956011)(99286004)(6306002)(6506007)(9686003)(102836004)(53546011)(316002)(8676002)(7696005)(76176011)(15650500001)(110136005)(14454004)(66574012)(256004)(6436002)(54906003)(86362001)(66446008)(64756008)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4008; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dzHy06BoeRa438QWwLVBjq0Mqp87B1NLJs+jW6Pa0pnqZL7iPsR7F9Yuxv9yZDkBp4z5BDKlDTJj7Kqp4JQok3ykQ5Slio7e2iQRo0bLn2qkQjuIFw9huumXH2eKoEqWe/Qo8CFjyKIcDZcnFz1ziq8xxfUTxC+AKOWe1I5A3eGd9SESishitcY9PaUT712McnTagjgjo7ZqGREPORZS03svbfzj+gfiuyD9bNZDSs2tAjnEMQSqZZim1hYWfAXx2I//37CvhwbXCez889WcOMyOmg7EGW9j+zLd+njNl5X1Hk3hHEPqD9T+Hg7cji8COfZT2JIsCYkKPLvdLbgNlvmOnJRbN38kky9R4uwv8pbKiyNpc84bw4CO42No3LmUeEapbdkTJqCfWNIVlPbCxOWixyWxtZKyOS9TMR9CNT0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ae77cc7-b501-401b-1751-08d6c495b8af X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 07:07:44.6146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4008 Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 07:07:52 -0000 Hi Fernando, I am not sure why it is important for you to update RFC 3552. The argument = that it requires specification authors to consider your document in securit= y and privacy considerations is not IMHO not correct. If you document provides useful guidance then it should stand on its own. A few random comments from looking at it: - FWIW you should be re-using terms defined in RFC 6973, such as identifier= . - Why are you acknowledging yourself in your own draft? - You use the RFC 2119 term as requirements for protocol authors rather tha= n for interoperability. I think you should mention this in the terminology = section somewhere or not use RFC2119 language. - You should define somewhere what you consider a "transient numeric identi= fier". - In the introduction and in the abstract you describe a problem with imple= mentations (you refer to TCP) but the recommendations later aim for protoco= l authors. In many cases the authors of the specification and not the imple= menters. Do you believe that you have solved the problem? More comments will follow... Ciao Hannes -----Original Message----- From: Secdispatch On Behalf Of Fernando Gont Sent: Donnerstag, 18. April 2019 23:50 To: Eric Rescorla Cc: Iv=E1n Arce (Quarkslab) ; IETF SecDispatch ; pearg@irtf.org; secdispatch-chairs@ietf.org Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 On 18/4/19 15:45, Eric Rescorla wrote: > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > wrote: > > Folks, > > At the last secdispatch meeting I presented our I-D > draft-gont-predictable-numeric-ids. > > >From the meeting discussion, it would seem to me that there is suppo= rt > for this work. > > It would also seem to me that part of this work is to be pursued in a= n > appropriate IRTF rg, while the update to RFC3552 > (draft-gont-numeric-ids-sec-considerations) should be pursued as an > AD-sponsored document. > > > I'm somewhat skeptical on an update to 3552; the proposed set of > things to be improved seems unclear. Can you please state what's unclear? We have 30+ years of history of screwing up numeric identifiers in the prot= ocols we specify. Just to name a few: * TCP ISNs * TCP ephemeral ports * DNS TxIDs * IPv4 Frag IDs * IPv6 Frag IDs * IPv6 IIDs * NTP port numbers * NTP timestamps * TCP timestamps .... and the list can continue. We are trying, for once and for all, to act proactively in this respect, to= avoid repeating the same history in every protocol we specify, and every i= mplementation that comes up. > I don't think that the material in this document should be added to > 3552, as the purpose of 3552 is not really to go into that kind of > detail about any specific topic. What I would expect is that RFC3552 helps prevent us from coming up with vu= lnerable implementations. Clearly, the history of flawed IDs seems to indic= ate that we are doing something wrong. At the time of this writing, it seems that RFC3552 is the document that dra= ft/RFC authors are required to read when it comes to how to do a security a= nalysis of their document. So I am curious why you think this doesn't belon= g to RFC3552. That said, this document is *updating* RFC3552, rather than a revision of R= FC3552. Therefore, the content in this document wouldn't become part of RFC= 3552, necessarily. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Apr 19 00:38:00 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0341200F7 for ; Fri, 19 Apr 2019 00:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 lY7t5FZYxQL6 for ; Fri, 19 Apr 2019 00:37:55 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130083.outbound.protection.outlook.com [40.107.13.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68F01200E3 for ; Fri, 19 Apr 2019 00:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B9d7DVJdOkYZp27AIVHcparD3QwAkljRSM/gMi+lnrk=; b=ZnOWTe1tOBwksmYLvdk4sB11xBr/Aw4N6PNFNqzDDTuXOaPhpes5nFsyJuHolgPYJEVT370UIVTYFm/H6bxRotQdMxu29y2q2zAbZ7Yr2ohGd8MSCV4mH2c6Gjpu7OYlSETYAVx5Uma7kiPNTl3iYn9qfgFPA/AkW1CppWkaOpY= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3064.eurprd08.prod.outlook.com (52.135.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Fri, 19 Apr 2019 07:37:51 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Fri, 19 Apr 2019 07:37:51 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , "Blomqvist, Peter" CC: Richard Barnes , "secdispatch@ietf.org" Thread-Topic: [Secdispatch] EDHOC Summary Thread-Index: AQHU9nALydCRJpj7+Eegv0GDPbsAqqZDEI4A Date: Fri, 19 Apr 2019 07:37:51 +0000 Message-ID: References: <1554794627589.50834@sony.com> <20190419052324.GB51586@kduck.mit.edu> In-Reply-To: <20190419052324.GB51586@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.121.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3256f57a-26b7-4620-d738-08d6c499edb1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3064; x-ms-traffictypediagnostic: AM6PR08MB3064: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0012E6D357 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(136003)(366004)(40434004)(199004)(13464003)(189003)(316002)(71190400001)(74316002)(71200400001)(54906003)(53936002)(55016002)(6306002)(478600001)(7736002)(486006)(110136005)(305945005)(66446008)(64756008)(73956011)(66946007)(9686003)(4326008)(102836004)(229853002)(33656002)(14454004)(5660300002)(53546011)(6116002)(3846002)(81166006)(97736004)(93886005)(25786009)(476003)(11346002)(446003)(68736007)(81156014)(6436002)(8936002)(86362001)(72206003)(52536014)(2171002)(6506007)(5024004)(7696005)(14444005)(186003)(26005)(966005)(8676002)(76176011)(2906002)(66476007)(256004)(6246003)(66556008)(66066001)(76116006)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3064; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3tzUO7QRh8DmEGoO/QeF4+Z8qii+u1f5EzqEvYm8I696VMR5+hkCARbjDK8M3QSoWjStsQK1vE0fIR8BXtXMWORPRsDsY5WcoR3ZNn6ckgXVCG11d6tRpGKVelnvVtLCbdy6iiv6PIMsqhtpc81PtF2MHCHjqtZi4iYGSXdybfnl8eBAGYeiluE3WzOyE1sSFPPbgc0ZCQPWU+5Xlb+Mg+0TuOgEvxVzy/vdb4MJjnbBY7ZOTRfXsh3uDROMC/sB0CMVs2blCrAk48svPGzJv8y/aJ1zMkmRQgPY6zA+6lMnRcc5oGjwwRf7bf0UJgex0blHd46DLDwzcdaDYQaeU3KvN/FawTwGv8hOcw0Ai/L20SzPMpIM9ikflPN+McqNcVwrknH1Bpmq4NbTzE2UGmiHPP16HihiOxK3Nc7Evr4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3256f57a-26b7-4620-d738-08d6c499edb1 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 07:37:51.5728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3064 Archived-At: Subject: Re: [Secdispatch] EDHOC Summary X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 07:37:58 -0000 Hi Ben, The size of flash is not determined by the microcontroller. My favorite too= l is the MCU finder from STM: https://www.st.com/en/development-tools/st-mc= u-finder.html You can get Cortex M0+ with 16, 32, 64, 128, and 192 kBytes. Cortex M4 typically provide larger flash size options, including 256, 512, = and 1024 Kbytes. The reason for the different flash size offerings is based= on anticipated product use. You can also attach off-chip flash to it. Depending on your firmware update= strategy this may make sense. Finally, in a product with a radio technology you will very often put the r= adio on a separate MCU. While it will cost you more (and will consume more = energy) it will make the overall system more stable and easier to develop. = Software development is also a cost factor. The stability aspect comes from= the need of the link layer protocols to react in specific time windows. Yo= u definitely don't want your application code to negatively impact the resp= onse time of your radio stack. Regarding battery lifetime it is really hard to say anything without knowin= g how the product really looks like. My co-workers tell me that the firmwar= e update is one of the most energy-draining protocol activities. For exampl= e, a firmware update on a BLE-based device (without any advanced techniques= like differential updates) consumes 50% of the coin-cell battery. It is also a question of how many key exchanges your really need to run. Yo= u assume a full key exchange once per month. Given that we are just develop= ing extensions like the CID the answer is that you don't necessarily need t= o make that many. Furthermore, there are concepts like session resumption t= hat allow you to reduce the overhead in a subsequent handshake. I once asked a co-worker, Peter Aldworth, to give a talk to the ACE group a= bout selecting the appropriate hardware for an IoT product. I will did out = the slides/recording because he also talked about energy efficiency. As an engineer I would put all the effort into making the firmware update p= rocedure more efficient because that's where you will gain a lot. Also optimizing the actual data delivery is important. Optimizing SenML, fo= r example, can lead to huge performance gains. A draft will follow on this = topic... Ciao Hannes -----Original Message----- From: Secdispatch On Behalf Of Benjamin Kadu= k Sent: Freitag, 19. April 2019 07:23 To: Blomqvist, Peter Cc: Richard Barnes ; secdispatch@ietf.org Subject: Re: [Secdispatch] EDHOC Summary On Tue, Apr 09, 2019 at 07:23:47AM +0000, Blomqvist, Peter wrote: > Hi Richard, > > > Code footprint is not extremely constrained, typically Cortex M4 or simil= ar. > > Battery however is constrained. Also data transport. > > > Optimistic marketing state that devices now can run 10 years on coin cell= s - adding security to such a battery budget is problematic to say the leas= t. At one point I looked at the numbers in https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/= slides-interim-2019-secdispatch-01-sessa-edhoc.pdf and tried to do some ballpark numbers on total power consumption for key ex= change over the lifetime of the device. I don't have a great handle on whe= ther, say, 1000 mAh is plausible for the usable energy in a coin cell, but = IIRC at one rekeying event per month and some similar assumptions I could g= et the lifetime energy consumption to be around 0.5% for the AKE. Hopefully someone could replicate those numbers (I don't remember where I p= ut my notes) and comment on how much slack there is in the power budget for= this sort of thing. -Ben _______________________________________________ Secdispatch mailing list Secdispatch@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Fri Apr 19 02:05:19 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0211200C5; Fri, 19 Apr 2019 02:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 jTbc61Sp4Uu4; Fri, 19 Apr 2019 02:05:16 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE81120044; Fri, 19 Apr 2019 02:05:15 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A0C8084A55; Fri, 19 Apr 2019 11:05:12 +0200 (CEST) To: Hannes Tschofenig , Eric Rescorla Cc: =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , IETF SecDispatch , "pearg@irtf.org" , "secdispatch-chairs@ietf.org" References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 11:03:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 09:05:18 -0000 On 19/4/19 09:07, Hannes Tschofenig wrote: > Hi Fernando, > > I am not sure why it is important for you to update RFC 3552. So that folks are required to do the corresponding analysis of numeric I-Ds as part of the security considerations section? FWIW, I think that's the *right* thing to do. That said, at this point, I can live without that, if that's the "showstopper". > The > argument that it requires specification authors to consider your > document in security and privacy considerations is not IMHO not > correct. If you document provides useful guidance then it should > stand on its own. Again, while I do think the right thing is to update RFC3552, I'm not planning to spend a lot of Joules fighting this point. > A few random comments from looking at it: > > - FWIW you should be re-using terms defined in RFC 6973, such as > identifier. Will check. Thanks for the pointer. > - Why are you acknowledging yourself in your own draft? - We're just noting that this document is a spin off of gont-predictable-numeric-ids, because: 1) We cannot predict the faith of the other pieces 2) The folks we credit didn't provide feedback on this particular doc, but on the larger document. Not crediting them would be unfair. Claiming that they provided feedback on *this* document would be incorrect/not-true. > You use the RFC 2119 term as requirements for protocol authors rather > than for interoperability. I think you should mention this in the > terminology section somewhere or not use RFC2119 language. Point taken. Will address this. Thanks! > - You > should define somewhere what you consider a "transient numeric > identifier". - In the introduction and in the abstract you describe a > problem with implementations (you refer to TCP) but the > recommendations later aim for protocol authors. In many cases the > authors of the specification and not the implementers. Do you believe > that you have solved the problem? Please see section 3: most of the times there are problems in the implementations is because the advice in the specs is flawed, or because the requirements are underspecified -- and hence the implementors have no option other than figuring out things by themselves. I can't think of a case of IDs where the specs did the right thing and the implementors screwed up. > More comments will follow... Look forward to them! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 19 02:15:56 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84594120044; Fri, 19 Apr 2019 02:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 TKa3UXn00Jfr; Fri, 19 Apr 2019 02:15:46 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F401A1200C5; Fri, 19 Apr 2019 02:15:45 -0700 (PDT) Received: from [192.168.1.103] (unknown [46.1.219.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8B2438457A; Fri, 19 Apr 2019 11:15:40 +0200 (CEST) To: Hannes Tschofenig , Eric Rescorla Cc: "pearg@irtf.org" , IETF SecDispatch , =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , "secdispatch-chairs@ietf.org" References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 19 Apr 2019 11:15:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Secdispatch] [Pearg] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 09:15:48 -0000 On 19/4/19 09:07, Hannes Tschofenig wrote: > Hi Fernando, > > I am not sure why it is important for you to update RFC 3552. The argument that it requires specification authors to consider your document in security and privacy considerations is not IMHO not correct. > If you document provides useful guidance then it should stand on its own. > > A few random comments from looking at it: > > - FWIW you should be re-using terms defined in RFC 6973, such as identifier. > - Why are you acknowledging yourself in your own draft? > - You use the RFC 2119 term as requirements for protocol authors rather than for interoperability. I think you should mention this in the terminology section somewhere or not use RFC2119 language. As an example: If you look at the requirements for ephemeral ports in RFC793 or RFC768, they are underspecified -- only the interoperability requirements are specified, and the implementer has to figure out the algorithm himself/herself. --- RFC6056 complements that. OTOH, the IPv6 Fragment ID generation in RFC2460 is overspecified: a global counter is suggested, leading to predictable Frag IDs, unnecessarily. IN both cases, there were implementations with predictable port numbers and predictable IPv6 Frag IDs. In the former case, because doing incremental port numbers was an easy way to comply with the*interoperability* requirements -- and the spec doesn't consider the predictability aspec. In the later case, the spec itself suggests an inappropriate IPv6 Frag ID generation algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 19 07:47:52 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44EF120159 for ; Fri, 19 Apr 2019 07:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 l5eFE3MjjOOz for ; Fri, 19 Apr 2019 07:47:48 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 50C85120166 for ; Fri, 19 Apr 2019 07:47:47 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id r24so4882212ljg.3 for ; Fri, 19 Apr 2019 07:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ncKEyVHeVOiesfYYk73ytfIB1Si52lC5VYv63SnAKAY=; b=aZL7w3hXwKRC6khfWsypFcncU67PL8pCdmKQcoL5HS3RFtucHMCXuw71lRGsvIpRQq 88N1c4TeagVLvylrNMZumY1D3n+j0jHITvg9n32CEQKTZbdGYPnyrGLiKwvaPz+YaqRW jAO5E3FKcqBQeGVOF5wKg4r6APvOG3QjvuIRbHWnzXCW6gSj4OIv4le9r71KODQfjasc ULdvoHC5N2ZqWjCiJWMtjS6OmrRyCo4+64uAQLIQcEf4oqzas/MWZYHCIS82qV2xsOB6 bIme2lH/o0sS+izaRkha970FudzwiWaGlw76lopp0r4OCPiqq5mnyATAFVMq0gvojbXD m9PA== 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=ncKEyVHeVOiesfYYk73ytfIB1Si52lC5VYv63SnAKAY=; b=LjcRIoQxxma9zf1NS+0AuVaxwT94+1L+2sM3lHJQYFDDefOI8ZomVZA6UfMOjkyyVQ CPu1ZrUJ30XTqTxKUO9nKdPNJTe0/Nnaq4QmsztOG3jBfNHs6pUzozN/MbtUtXpg17Zd vNTiLJnTwa5ayZ74Uv2QdJAkPVNXwDKnuIGgIDdPXr0ITi18vlD3mjrcjYRnIC3MdtH2 R7nWEosrGANakVjdEHE58Mbqa66Lkhb45aRhDSHnD8ZNVWEB5dshXpKI+hRvLW2jEfc2 OQghhXELOG7EGGt6BzbCNq6+jtfchO/yMlQQih7gVer6ftcbLFO+oEL5c4pz/D31GBvs MvPA== X-Gm-Message-State: APjAAAXalWR/RPO8wp2CvgKU/xSzS8relmUfWtgeRkW3t9NDtExOVCVe Of2xGSUDxmMTwi8f8ZozcHGyDLDCi6queU1cpsZMzw== X-Google-Smtp-Source: APXvYqzybPfoKyQQEU4eO1jdERF9iOOv87keKd33kz5nC2rzwzlbNxwIiWmh1Zh1pqdXGoiU1slSCYwtSyi9yvB8eVM= X-Received: by 2002:a2e:9194:: with SMTP id f20mr2561166ljg.10.1555685265516; Fri, 19 Apr 2019 07:47:45 -0700 (PDT) MIME-Version: 1.0 References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> <20190419012507.GB95327@kduck.mit.edu> In-Reply-To: <20190419012507.GB95327@kduck.mit.edu> From: Eric Rescorla Date: Fri, 19 Apr 2019 07:47:07 -0700 Message-ID: To: Benjamin Kaduk Cc: Fernando Gont , IETF SecDispatch , pearg@irtf.org, =?UTF-8?Q?Iv=C3=A1n_Arce_=28Quarkslab=29?= , secdispatch-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a259630586e333da" Archived-At: Subject: Re: [Secdispatch] [Pearg] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 14:47:51 -0000 --000000000000a259630586e333da Content-Type: text/plain; charset="UTF-8" On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk wrote: > On Thu, Apr 18, 2019 at 05:01:17PM -0700, Eric Rescorla wrote: > > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont > wrote: > > > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > > wrote: > > > > > > > > On 18/4/19 15:45, Eric Rescorla wrote: > > > > > > > > > > > > > > > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > > > > > > > >> > > > wrote: > > > > > > > > > > Folks, > > > > > > > > > > At the last secdispatch meeting I presented our I-D > > > > > draft-gont-predictable-numeric-ids. > > > > > > > > > > >From the meeting discussion, it would seem to me that > there > > > > is support > > > > > for this work. > > > > > > > > > > It would also seem to me that part of this work is to be > > > > pursued in an > > > > > appropriate IRTF rg, while the update to RFC3552 > > > > > (draft-gont-numeric-ids-sec-considerations) should be > pursued > > > > as an > > > > > AD-sponsored document. > > > > > > > > > > > > > > > I'm somewhat skeptical on an update to 3552; the proposed set > of > > > > things > > > > > to be improved seems unclear. > > > > > > > > Can you please state what's unclear? > > > > > > > > > > > > I understand the list of things in your document. However, there have > > > > been proposals for a larger revision to 3552. > > > > > > There was an effort to revise RFC3552. It just didn't happen. Looks > like > > > trying to boil the ocean wasn't the best idea. > > > > > > > Yes. > > > > > > > > > > > > It's a total of 9 pages. If you remove abstract, boilerplate, and > > > references, you end up with ~4 pages. In fact, the update (and > > > indispensable text) is that in Section 5, and boils down to: > > > > > > ---- cut here ---- > > > 5. Security and Privacy Requirements for Identifiers > > > > > > Protocol specifications that specify transient numeric identifiers > > > MUST: > > > > > > 1. Clearly specify the interoperability requirements for the > > > aforementioned identifiers. > > > > > > 2. Provide a security and privacy analysis of the aforementioned > > > identifiers. > > > > > > 3. Recommend an algorithm for generating the aforementioned > > > identifiers that mitigates security and privacy issues, such as > > > those discussed in [I-D.gont-predictable-numeric-ids]. > > > ---- cut here ---- > > > > > > > Eh, I think something like this would have been OK in 3552; I'm not > > sure that it's necessary to add at this point to the list of things that > > 3552 considers. > > > > > > > > > > That said, this document is *updating* RFC3552, rather than a > > > revision > > > > of RFC3552. Therefore, the content in this document wouldn't > become > > > part > > > > of RFC3552, necessarily. > > > > > > > > > > > > Well, the semantics of "Updates" would be somewhat confusing here. > > > > Certainly I don't think that this document is something we need to > > > > transitively incorporate into 3552, but I care a lot less about the > > > > contents of this header than I do about whether 3552 should be > updated > > > > to include this material. > > > > > > I do think RFC3552 should be updated as indicated (this stuff is > general > > > enough to be covered there). > > > > > > That said, the high-order bit here is to do something to prevent the > bad > > > history we have wrt numeric ids from repeating itself. > > > > > > If the whole point is that you'd like the "Updates: 3552 (if approved)" > > > header to be removed (along with references to "updating RFC3552"), > > > please say so. > > > > > > No, that's not my point. As I said, I don't think we should publish a new > > version > > of 3552 with this material or similar material in it. I don't much care > one > > way > > or the other whether this document is published, and while I don't think > > marking > > it as updating 3552 is that helpful, I'm not going to die on that hill > > either. > > Do you care to state an opinion on "Updates: 3552" vs. an additional > document in BCP 72 (vs. both or none)? > I don't really think either of them matters much one way or the other. -Ekr > Thanks, > > Ben > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --000000000000a259630586e333da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 18, 2019 at 6:25 PM Benja= min Kaduk <kaduk@mit.edu> wrote:=
On Thu, Apr 18,= 2019 at 05:01:17PM -0700, Eric Rescorla wrote:
> On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont <fgont@si6networks.com> wrote:=
>
> > On 19/4/19 01:09, Eric Rescorla wrote:
> > >
> > >
> > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont <fgont@si6networks.com<= br> > > > <mailto:fgont@si6networks.com>> wrote:
> > >
> > >=C2=A0 =C2=A0 =C2=A0On 18/4/19 15:45, Eric Rescorla wrote: > > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0> On Tue, Apr 16, 2019 at 2:07 AM Fern= ando Gont
> > >=C2=A0 =C2=A0 =C2=A0<fgont@si6networks.com <mailto:fgont@si6networks.com> > > >=C2=A0 =C2=A0 =C2=A0> <mailto:fgont@si6networks.com <mailto:fgont@si6networks.co= m>>>
> > wrote:
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Folks,
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0At the last secdi= spatch meeting I presented our I-D
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0draft-gont-predic= table-numeric-ids.
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>From the meet= ing discussion, it would seem to me that there
> > >=C2=A0 =C2=A0 =C2=A0is support
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0for this work. > > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0It would also see= m to me that part of this work is to be
> > >=C2=A0 =C2=A0 =C2=A0pursued in an
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0appropriate IRTF = rg, while the update to RFC3552
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0(draft-gont-numer= ic-ids-sec-considerations) should be pursued
> > >=C2=A0 =C2=A0 =C2=A0as an
> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0AD-sponsored docu= ment.
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0>
> > >=C2=A0 =C2=A0 =C2=A0> I'm somewhat skeptical on an upd= ate to 3552; the proposed set of
> > >=C2=A0 =C2=A0 =C2=A0things
> > >=C2=A0 =C2=A0 =C2=A0> to be improved seems unclear.
> > >
> > >=C2=A0 =C2=A0 =C2=A0Can you please state what's unclear?<= br> > > >
> > >
> > > I understand the list of things in your document. However, t= here have
> > > been proposals for a larger revision to 3552.
> >
> > There was an effort to revise RFC3552. It just didn't happen.= Looks like
> > trying to boil the ocean wasn't the best idea.
> >
>
> Yes.
>
>
>
> >
> > It's a total of 9 pages. If you remove abstract, boilerplate,= and
> > references, you end up with ~4 pages. In fact, the update (and > > indispensable text) is that in Section 5, and boils down to:
> >
> > ---- cut here ----
> > 5.=C2=A0 Security and Privacy Requirements for Identifiers
> >
> >=C2=A0 =C2=A0 Protocol specifications that specify transient numer= ic identifiers
> >=C2=A0 =C2=A0 MUST:
> >
> >=C2=A0 =C2=A0 1.=C2=A0 Clearly specify the interoperability requir= ements for the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 aforementioned identifiers.
> >
> >=C2=A0 =C2=A0 2.=C2=A0 Provide a security and privacy analysis of = the aforementioned
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 identifiers.
> >
> >=C2=A0 =C2=A0 3.=C2=A0 Recommend an algorithm for generating the a= forementioned
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 identifiers that mitigates security an= d privacy issues, such as
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 those discussed in [I-D.gont-predictab= le-numeric-ids].
> > ---- cut here ----
> >
>
> Eh, I think something like this would have been OK in 3552; I'm no= t
> sure that it's necessary to add at this point to the list of thing= s that
> 3552 considers.
>
>
>
> > >=C2=A0 =C2=A0 =C2=A0That said, this document is *updating* RF= C3552, rather than a
> > revision
> > >=C2=A0 =C2=A0 =C2=A0of RFC3552. Therefore, the content in thi= s document wouldn't become
> > part
> > >=C2=A0 =C2=A0 =C2=A0of RFC3552, necessarily.
> > >
> > >
> > > Well, the semantics of "Updates" would be somewhat= confusing here.
> > > Certainly I don't think that this document is something = we need to
> > > transitively incorporate into 3552, but I care a lot less ab= out the
> > > contents of this header than I do about whether 3552 should = be updated
> > > to include this material.
> >
> > I do think RFC3552 should be updated as indicated (this stuff is = general
> > enough to be covered there).
> >
> > That said, the high-order bit here is to do something to prevent = the bad
> > history we have wrt numeric ids from repeating itself.
> >
> > If the whole point is that you'd like the "Updates: 3552= (if approved)"
> > header to be removed (along with references to "updating RFC= 3552"),
> > please say so.
>
>
> No, that's not my point. As I said, I don't think we should pu= blish a new
> version
> of 3552 with this material or similar material in it. I don't much= care one
> way
> or the other whether this document is published, and while I don't= think
> marking
> it as updating 3552 is that helpful, I'm not going to die on that = hill
> either.

Do you care to state an opinion on "Updates: 3552" vs. an additio= nal
document in BCP 72 (vs. both or none)?

= I don't really think either of them matters much one way or the other.<= /div>

-Ekr


Thanks,

Ben

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--000000000000a259630586e333da-- From nobody Sat Apr 20 10:57:07 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8136A120162; Sat, 20 Apr 2019 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 A7AXZrfGkFlQ; Sat, 20 Apr 2019 10:56:55 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EEE12016B; Sat, 20 Apr 2019 10:56:54 -0700 (PDT) Received: from [192.168.0.148] (unknown [88.247.88.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4D40C84BC0; Sat, 20 Apr 2019 19:56:39 +0200 (CEST) To: Eric Rescorla , Benjamin Kaduk Cc: IETF SecDispatch , pearg@irtf.org, =?UTF-8?Q?Iv=c3=a1n_Arce_=28Quarkslab=29?= , secdispatch-chairs@ietf.org References: <4ac730a6-73ca-74cd-e848-4a6645bd0403@si6networks.com> <20190419012507.GB95327@kduck.mit.edu> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <32c21255-5840-529e-4f6d-4d65966d88d4@si6networks.com> Date: Sat, 20 Apr 2019 19:48:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Secdispatch] [Pearg] Numeric IDs: Update to RFC3552 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 17:56:59 -0000 On 19/4/19 16:47, Eric Rescorla wrote: > > > On Thu, Apr 18, 2019 at 6:25 PM Benjamin Kaduk > wrote: > > On Thu, Apr 18, 2019 at 05:01:17PM -0700, Eric Rescorla wrote: > > On Thu, Apr 18, 2019 at 4:40 PM Fernando Gont > > wrote: > > > > > On 19/4/19 01:09, Eric Rescorla wrote: > > > > > > > > > > > > On Thu, Apr 18, 2019 at 3:03 PM Fernando Gont > > > > > >> > wrote: > > > > > > > >     On 18/4/19 15:45, Eric Rescorla wrote: > > > >     > > > > >     > > > > >     > On Tue, Apr 16, 2019 at 2:07 AM Fernando Gont > > > >      > > > > > >     > >>> > > > wrote: > > > >     > > > > >     >     Folks, > > > >     > > > > >     >     At the last secdispatch meeting I presented our I-D > > > >     >     draft-gont-predictable-numeric-ids. > > > >     > > > > >     >     >From the meeting discussion, it would seem to me > that there > > > >     is support > > > >     >     for this work. > > > >     > > > > >     >     It would also seem to me that part of this work is to be > > > >     pursued in an > > > >     >     appropriate IRTF rg, while the update to RFC3552 > > > >     >     (draft-gont-numeric-ids-sec-considerations) should > be pursued > > > >     as an > > > >     >     AD-sponsored document. > > > >     > > > > >     > > > > >     > I'm somewhat skeptical on an update to 3552; the > proposed set of > > > >     things > > > >     > to be improved seems unclear. > > > > > > > >     Can you please state what's unclear? > > > > > > > > > > > > I understand the list of things in your document. However, > there have > > > > been proposals for a larger revision to 3552. > > > > > > There was an effort to revise RFC3552. It just didn't happen. > Looks like > > > trying to boil the ocean wasn't the best idea. > > > > > > > Yes. > > > > > > > > > > > > It's a total of 9 pages. If you remove abstract, boilerplate, and > > > references, you end up with ~4 pages. In fact, the update (and > > > indispensable text) is that in Section 5, and boils down to: > > > > > > ---- cut here ---- > > > 5.  Security and Privacy Requirements for Identifiers > > > > > >    Protocol specifications that specify transient numeric > identifiers > > >    MUST: > > > > > >    1.  Clearly specify the interoperability requirements for the > > >        aforementioned identifiers. > > > > > >    2.  Provide a security and privacy analysis of the aforementioned > > >        identifiers. > > > > > >    3.  Recommend an algorithm for generating the aforementioned > > >        identifiers that mitigates security and privacy issues, > such as > > >        those discussed in [I-D.gont-predictable-numeric-ids]. > > > ---- cut here ---- > > > > > > > Eh, I think something like this would have been OK in 3552; I'm not > > sure that it's necessary to add at this point to the list of > things that > > 3552 considers. > > > > > > > > > >     That said, this document is *updating* RFC3552, rather than a > > > revision > > > >     of RFC3552. Therefore, the content in this document > wouldn't become > > > part > > > >     of RFC3552, necessarily. > > > > > > > > > > > > Well, the semantics of "Updates" would be somewhat confusing here. > > > > Certainly I don't think that this document is something we need to > > > > transitively incorporate into 3552, but I care a lot less > about the > > > > contents of this header than I do about whether 3552 should be > updated > > > > to include this material. > > > > > > I do think RFC3552 should be updated as indicated (this stuff is > general > > > enough to be covered there). > > > > > > That said, the high-order bit here is to do something to prevent > the bad > > > history we have wrt numeric ids from repeating itself. > > > > > > If the whole point is that you'd like the "Updates: 3552 (if > approved)" > > > header to be removed (along with references to "updating RFC3552"), > > > please say so. > > > > > > No, that's not my point. As I said, I don't think we should > publish a new > > version > > of 3552 with this material or similar material in it. I don't much > care one > > way > > or the other whether this document is published, and while I don't > think > > marking > > it as updating 3552 is that helpful, I'm not going to die on that hill > > either. > > Do you care to state an opinion on "Updates: 3552" vs. an additional > document in BCP 72 (vs. both or none)? FWIW, our take is that by formally updating rfc3552 protocol specs would be forced to do the write thing, numeric identifiers would be subject to the right analysis, and the security considerations would need to include a security/privacy assessment of any numeric identifiers employed/specified in the corresponding spec. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 22 09:14:13 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD412032C for ; Mon, 22 Apr 2019 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNVsW0EQOsaf for ; Mon, 22 Apr 2019 09:14:03 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8D61202F0 for ; Mon, 22 Apr 2019 09:14:03 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id v1so567333lfg.5 for ; Mon, 22 Apr 2019 09:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GEW1LAJQCuAZgOIlfV1y6CYcdyDU/UZdeMC1Y2VqAQw=; b=ZfbnBDsXwpcrRFzE5SMDdqvyfYV0LvHPfaAIvRjswzUR1wdTwdn4LRuxjCvGl/tKfv lxtqmfzvD8suy4/ET7gax/YXSmFFWBJ4LbrdYh2FManHtwRYqn10fqjEkCJ0cMGEutyl 7xIVgYCfOfEsgjedF6bhzme8l3vqCkEDV4G/mTeGiUGlAQWetjF1FCRWQYoZl0GlSbxC PKKkyOD8DGqphdag3GXd1cu9dJiYXZvtzRr9YonGE7hh2frf6Tv0Uv/RAbVBnAVVcBZL 6r9kdBlrGNUcUCXtQvairpNtJ1q1turVf6DXFGMGPxXPUi6zZlRzgReNT7OYKZrYHunD h7FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GEW1LAJQCuAZgOIlfV1y6CYcdyDU/UZdeMC1Y2VqAQw=; b=KMgwgTRRG8AL3Fjj3J9xA7FciFBsAW+a0L4QLzCfHU3mmfqEnhctjFQPurHc/GJjV7 D2rsy8LOpiNmnZ/yKEy+7WhlcBI6eToEcF8mCKXmmWH6EjL3PBgVHAz25MTPlwKqsyXD qxYrnURXwYFywTRqL/IDOT5P8Z7GkFDiPkxjWXAAZ7O20iELO94QY5x9s/FIOpa0SYCY ICQTJYKocrELIqm5AbusfP3RrI9bB7qALURhztn/iVen8apiGW1R3ns1e2TB7xa8UPm4 uhvNXRyC1S4rKcNH8VmoP3XNHLnj9jLDnjZwiAUMHQM8jcnjuhCO4TEF3+Miyz1SlJuC ciJg== X-Gm-Message-State: APjAAAWI/ypM2/z6Cv6MjVZqHksaMM0H7YSS9LzZz9CRSKZfX3Sh9QOP evZQNvgNRpdLmOdUj+NA7swdYzFWGLXOc+gR4vJRXJMm X-Google-Smtp-Source: APXvYqxqPR4hUwFqSOXwnpjJyJBqtnPgkapqP+sQzuvDC5t0a+gls4lHXJpjPgZco1vuTmU9Mx+2wNLmUgEuPpxmdwY= X-Received: by 2002:ac2:5222:: with SMTP id i2mr10286388lfl.68.1555949641321; Mon, 22 Apr 2019 09:14:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 22 Apr 2019 09:13:50 -0700 Message-ID: To: secdispatch Content-Type: multipart/alternative; boundary="000000000000a8d1c9058720c1fc" Archived-At: Subject: Re: [Secdispatch] Introducing MASQUE X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 16:14:08 -0000 --000000000000a8d1c9058720c1fc Content-Type: text/plain; charset="UTF-8" Hi everyone, To follow up on this, we now have an IETF mailing list dedicated to MASQUE: masque@ietf.org We plan on continuing the conversation there, please join us if you're interested: https://www.ietf.org/mailman/listinfo/masque Thanks, David On Mon, Mar 18, 2019 at 12:26 PM David Schinazi wrote: > Hi secdispatch, > > I'd like to share a draft I've recently uploaded: > https://tools.ietf.org/html/draft-schinazi-masque-00 > > It introduces MASQUE, a protocol for obfuscating a VPN server inside an > HTTP/3 (or HTTP/2) web server. The proposal is pretty new so we'd love to > hear some opinions about how effectively it meets its security goals (or, > alternatively: how poorly it runs its own crypto). > > We'll be presenting the draft in Prague - at secdispatch to review the > security aspects and in tsv-area to look into the transport impact. > > Thanks, > David > --000000000000a8d1c9058720c1fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

To follow= up on this, we now have an IETF mailing list dedicated to MASQUE:=C2=A0masque@ietf.org

We plan on continuing the conversation there, please join us if you'r= e interested:

Thanks,
David


On Mon, Mar 18, 2019= at 12:26 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
--000000000000a8d1c9058720c1fc-- From nobody Mon Apr 22 09:58:28 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D261200A0; Mon, 22 Apr 2019 09:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 E5Mj4y57kp5z; Mon, 22 Apr 2019 09:58:24 -0700 (PDT) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (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 D8E99120091; Mon, 22 Apr 2019 09:58:23 -0700 (PDT) Received: by mail-ot1-f65.google.com with SMTP id s24so10153336otk.13; Mon, 22 Apr 2019 09:58:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NANW3Velgj3v0845qkySToXaLou64kAJSaZJYOaNpvE=; b=iKGKGQwp2QtDAp9Vtk6c824fvlBYC2TQYFy5WsbQqKZ5BBPThPKPmOwyIhHeuc2BTc CjMFXMaC+CroDdJy12xDW3ULqAw6tkmVvWlMcRaaRcnmKxkhzkOtbTi4YWWI0eZDiXsP oZ2ugF6k7mdSFVtcQs0H6FIPHjkVzeCiLntO26uEPXdUVrZKwwsnk/UHiCo5cK8eIKNE wM7WNkNVSBx1I/o8qQ1FGt3WX3lOVUj9nBiDhr3fhIisooDrLqhphXYo/yNyLGVS+D/2 OLFLkKLK1dpRBp2ndieXAw39uFIzM1RmIx/He06gh73ZQCguYrVd2Tivw0Fq19VK3nfn 6DaA== X-Gm-Message-State: APjAAAXvyxyOS6OT4G3qNeYmFc6QkJ7Qd85QuCh4r3NQYU4jx9tkedgY ji8d7NZDKwosZdBEEdoGXPy0VkSa4F6BHubmmqGcWtyW X-Google-Smtp-Source: APXvYqy3vY0P2gO0y864k5LORwVNrH15iMK2l+YAGe0vjuOGaZFl8Vd3pq4wJVQGfIRifdoBWthkZLUK8eOOQnep1sU= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr11458716oth.361.1555952302512; Mon, 22 Apr 2019 09:58:22 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 12:58:11 -0400 Message-ID: To: secdispatch@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000475fbf05872160f6" Archived-At: Subject: [Secdispatch] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 16:58:26 -0000 --000000000000475fbf05872160f6 Content-Type: text/plain; charset="UTF-8" Five years ago I started to look at the reasons that Internet users do not use end-to-end secure mail despite the fact that almost every email client in use supported S/MIME and OpenPGP had been available for decades. In answering that question, I quickly realized that we were trying to solve the problems we were interested in rather than the ones that the user actually cared about. And yes, users do really care about security but their security concerns are much broader than the ones raised on the cypherpunks mailing lists. They are concerned about the control that corporations might have over them much more than governments. They are concerned with the risk of losing the pictures of their kids at 5 years old to ransomware. Carl Ellison says that the user base of any security protocol halves for each click required to use it. This led me to ask, 'how can we reduce total user effort' and not just effort required for security. Today we ask the user to configure their email client twice, first to make use of email and again to make email secure (and then we require them to redo the second annually for S/MIME). The result of this approach is an infrastructure I call the Mathematical Mesh which I would like IETF participants to consider as a standards track effort, either in part or in whole. The goal of the Mesh is to make computers easier to use by making them more secure. This is easier than people might imagine. The key here is that every set of instructions that you write down and give to a human can be written as code and given to a suitably authorized computer system. The phrase suitably authorized is key here, often the reason manual intervention is required to configure systems requires is that certain system privileges are needed. Like BitCoin, the Mesh extends the traditional cryptographic repertoire. While all of the cryptographic techniques used in the Mesh are well established in the academic field, this is the first time anyone has (to my knowledge) proposed making use of them in an open standard. The Mesh is designed to make full use of the capabilities of modern computer systems: It is assumed that every user has access to a machine with at least the capability of a Raspberry Pi Zero for purposes of configuring an managing devices. Connection and use of constrained devices of Arduino Mega class and above is also supported by offloading certain security functions to a trusted gateway. I am posting this here to solicit opinions as to whether I should bring some or all of this work to the IETF or if I should take it to other forums. The drafts are available in plaintext or HTML format. Since some of the drafts make extensive use of mathematical notations, I recommend reading them in the HTML format. HTML: http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html Plaintext: https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-dare/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-trust/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/ These drafts are not yet complete as the example material and schema documentation is still being revised. This will be addressed as the reference code passes the remaining unit tests for each functional unit. The principle adopted being that it is better to have no examples than incorrect ones. The following drafts are planned but not yet written: https://datatracker.ietf.org/doc/draft-hallambaker-mesh-constrained/ https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantum/ The reference code is open source and runs in C# under .net Core. It is currently tested only on the Windows platform but previous versions have run on OSX and Linux. https://github.com/hallambaker/Mathematical-Mesh The code system is also open source. These tools allowed me to design, implement and document a code base that is capable of performing significant portions of the functions of PKIX, S/MIME, Blockchain, SMTP, IMAP and TLS on my own in a little less than three years. https://github.com/hallambaker/PHB-Build-Tools --000000000000475fbf05872160f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Five years ago I started to look at the reasons that Internet users do not = use end-to-end secure mail despite the fact that almost every email client = in use supported S/MIME and OpenPGP had been available for decades.

In answering that question, I = quickly realized that we were trying to solve the problems we were interest= ed in rather than the ones that the user actually cared about. And yes, use= rs do really care about security but their security concerns are much broad= er than the ones raised on the cypherpunks mailing lists. They are concerne= d about the control that corporations might have over them much more than g= overnments. They are concerned with the risk of losing the pictures of thei= r kids at 5 years old to ransomware.

Carl Ellison says that the user base of any security protocol h= alves for each click required to use it. This led me to ask, 'how can w= e reduce total user effort' and not just effort required for security. = Today we ask the user to configure their email client twice, first to make = use of email and again to make email secure (and then we require them to re= do the second annually for S/MIME).

The result of this approach is an infrastructure I call the Math= ematical Mesh which I would like IETF participants to consider as a standar= ds track effort, either in part or in whole.

The goal of the Mesh is to make computers easier to us= e by making them more secure. This is easier than people might imagine. The= key here is that every set of instructions that you write down and give to= a human can be written as code and given to a suitably authorized computer= system.

The phrase suita= bly authorized is key here, often the reason manual intervention=C2=A0is required to=C2=A0configure systems requires is = that certain system privileges are needed.

Like BitCoin, the Mesh extends the traditional cryptograp= hic repertoire. While all of the cryptographic techniques used in the Mesh = are well established in the academic field, this is the first time anyone h= as (to my knowledge) proposed making use of them in an open standard.
=

The Mesh is designed to make f= ull use of the capabilities of modern computer systems: It is assumed that = every user has access to a machine with at least the capability of a Raspbe= rry Pi Zero for purposes of configuring an managing devices. Connection and= use of constrained devices of Arduino Mega class and above is also support= ed by offloading certain security functions to a trusted gateway.

I am posting this here to solicit = opinions as to whether I should bring some or all of this work to the IETF = or if I should take it to other forums.

The drafts are available in plaintext or HTML format. Since = some of the drafts make extensive use of mathematical notations, I recommen= d reading them in the HTML format.

HTML:
http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture= .html=C2=A0=C2=A0
http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html= =C2=A0
http://= mathmesh.com/Documents/draft-hallambaker-mesh-dare.html=C2=A0
http://mathmesh.com/Do= cuments/draft-hallambaker-mesh-schema.html=C2=A0=C2=A0
http://mathmesh.com/Documents/draft= -hallambaker-mesh-cryptography.html=C2=A0=C2=A0

Plaintext:
https://datatracker.ietf.org/doc/draft-ha= llambaker-mesh-architecture/=C2=A0
http= s://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/
https://datatracker.ietf.org/doc/draft-hallambaker-m= esh-dare/
https://datatracker.ie= tf.org/doc/draft-hallambaker-mesh-schema/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/
https://datatracker.ietf.org/doc/d= raft-hallambaker-mesh-trust/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/

These drafts are not yet complete as the example material and schema do= cumentation is still being revised. This will be addressed as the reference= code passes the remaining unit tests for each functional unit. The princip= le adopted being that it is better to have no examples than incorrect ones.=

T= he following drafts are planned but not yet written:

https://datatracke= r.ietf.org/doc/draft-hallambaker-mesh-constrained/
https://datatracker.ietf.org/doc/draft-hallambaker-mes= h-quantum/

The reference code is open source and runs in C# under .= net Core. It is currently tested only on the Windows platform but previous = versions have run on OSX and Linux.

<= /div>
https://github.com/hallambaker/Mathematical-Mesh=C2= =A0=C2=A0

The code system is also open source. These tools allowed me to = design, implement and document a code base that is capable of performing si= gnificant portions of the functions of PKIX, S/MIME, Blockchain, SMTP, IMAP= and TLS on my own in a little less than three years.

https://github.com/hallambaker/PHB-Buil= d-Tools=C2=A0=C2=A0
=
--000000000000475fbf05872160f6-- From nobody Mon Apr 22 10:34:33 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE87120044 for ; Mon, 22 Apr 2019 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYmQZcH3QOaD for ; Mon, 22 Apr 2019 10:34:28 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 F3D6D1200DF for ; Mon, 22 Apr 2019 10:34:27 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id i21so9036551oib.11 for ; Mon, 22 Apr 2019 10:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=saXjQWBHFGZpWyT6o8DxU6FtSo4gVf1HfChXtt8kFso=; b=U1arV25jaYod9kYEXSplA78hY0meV/akF5wY5Ar1fYCcurBzdqoqgUb5dJ7EmkSQQ3 t4ddMKys8KePWiyA2xOE1Lpkb6fwz5dsrQa/M8cM2vW2l03nrbiKT29KOjB3ZiquYIjm K3KecIp0IQpsC8XZw9R4bm98dIrtyYpop1Z2iwwvAMZASECIZMAZy9LpfGF3KTIcLHWM cY03ai0vo0CgsCagZ6O0I2CVSygcubqxoL+rzbUrP/lQ6elMOYRYR5rq2LPN+v/d6Hsm tW2WVq9e2SKPZi0Ll1hwKvcuXYk+xXzZ15WZM6ySxS55oFg+lFKbxuair7qgneTAzMuR gDCA== 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=saXjQWBHFGZpWyT6o8DxU6FtSo4gVf1HfChXtt8kFso=; b=iDOVN1BDQrxD6GormHx1HLb/qqOzaHnpDU23DwZ09Q7KhHpB25/CEePBYNJHsi0FVC B20WvzssPuXH2q8Kuy121bD/Bwrm8vEpgFFJw1wlXbaaDcKs3kKo0wDcJq0cedOjbEz5 H8/d2mqxi+EUbnV73c1bj8/huL3PaYBzOecnMtcpsTazO9/CLIGlvukJnl6I4GuZy6Yt Gi6dWKhyjG78P+WGOsAc/PiiJ+6depilnXlSkslD6Dp+0dP9m3OOizbx14XBIGPeNonu HL+nw2gT0EkILtu0T92YTVTdy7ZtCAFR+tReNnZjSfdY6RA/s+DiN9fyPumqOKt19qF+ kRxQ== X-Gm-Message-State: APjAAAVpGoYdSxiqnjuI8BF2wpkicn3wo9b/+18eoxG83ObHh3HCie/N fCNU7vSsGAXmr7D2pgq77eUr3SqL+N6sLXh7ySyTUw== X-Google-Smtp-Source: APXvYqwRSyH6CosoZ7P9o3/1GVzxOSF3jUSPg3GhcNgI8Bt8ODl8P7qSnm0+FDK76aze2ePrKKf0Iv2L3tSkPawdgUI= X-Received: by 2002:aca:544b:: with SMTP id i72mr10114079oib.51.1555954466947; Mon, 22 Apr 2019 10:34:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 22 Apr 2019 13:34:06 -0400 Message-ID: To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000004a1e74058721e19e" Archived-At: Subject: Re: [Secdispatch] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 17:34:32 -0000 --0000000000004a1e74058721e19e Content-Type: text/plain; charset="UTF-8" Hi Phil, Thanks for the note. The IETF typically works on specifications for interoperability between multiple implementations. Is there more than one party involved / interested in implementing? --Richard On Mon, Apr 22, 2019 at 12:58 PM Phillip Hallam-Baker wrote: > Five years ago I started to look at the reasons that Internet users do not > use end-to-end secure mail despite the fact that almost every email client > in use supported S/MIME and OpenPGP had been available for decades. > > In answering that question, I quickly realized that we were trying to > solve the problems we were interested in rather than the ones that the user > actually cared about. And yes, users do really care about security but > their security concerns are much broader than the ones raised on the > cypherpunks mailing lists. They are concerned about the control that > corporations might have over them much more than governments. They are > concerned with the risk of losing the pictures of their kids at 5 years old > to ransomware. > > Carl Ellison says that the user base of any security protocol halves for > each click required to use it. This led me to ask, 'how can we reduce total > user effort' and not just effort required for security. Today we ask the > user to configure their email client twice, first to make use of email and > again to make email secure (and then we require them to redo the second > annually for S/MIME). > > The result of this approach is an infrastructure I call the Mathematical > Mesh which I would like IETF participants to consider as a standards track > effort, either in part or in whole. > > The goal of the Mesh is to make computers easier to use by making them > more secure. This is easier than people might imagine. The key here is that > every set of instructions that you write down and give to a human can be > written as code and given to a suitably authorized computer system. > > The phrase suitably authorized is key here, often the reason manual > intervention is required to configure systems requires is that certain > system privileges are needed. > > Like BitCoin, the Mesh extends the traditional cryptographic repertoire. > While all of the cryptographic techniques used in the Mesh are well > established in the academic field, this is the first time anyone has (to my > knowledge) proposed making use of them in an open standard. > > The Mesh is designed to make full use of the capabilities of modern > computer systems: It is assumed that every user has access to a machine > with at least the capability of a Raspberry Pi Zero for purposes of > configuring an managing devices. Connection and use of constrained devices > of Arduino Mega class and above is also supported by offloading certain > security functions to a trusted gateway. > > I am posting this here to solicit opinions as to whether I should bring > some or all of this work to the IETF or if I should take it to other forums. > > The drafts are available in plaintext or HTML format. Since some of the > drafts make extensive use of mathematical notations, I recommend reading > them in the HTML format. > > HTML: > http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture..html > > http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html > http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html > > http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html > > Plaintext: > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-dare/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-trust/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/ > > These drafts are not yet complete as the example material and schema > documentation is still being revised. This will be addressed as the > reference code passes the remaining unit tests for each functional unit. > The principle adopted being that it is better to have no examples than > incorrect ones. > > The following drafts are planned but not yet written: > > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-constrained/ > https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantum/ > > The reference code is open source and runs in C# under .net Core. It is > currently tested only on the Windows platform but previous versions have > run on OSX and Linux. > > https://github.com/hallambaker/Mathematical-Mesh > > The code system is also open source. These tools allowed me to design, > implement and document a code base that is capable of performing > significant portions of the functions of PKIX, S/MIME, Blockchain, SMTP, > IMAP and TLS on my own in a little less than three years. > > https://github.com/hallambaker/PHB-Build-Tools > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000004a1e74058721e19e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Phil,

Thanks for the note= .=C2=A0 The IETF typically works on specifications for interoperability bet= ween multiple implementations.=C2=A0 Is there more than one party involved = / interested in implementing?

--Richard
<= /div>
O= n Mon, Apr 22, 2019 at 12:58 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Five years ago I started to lo= ok at the reasons that Internet users do not use end-to-end secure mail des= pite the fact that almost every email client in use supported S/MIME and Op= enPGP had been available for decades.

In answering that question, I quickly realized that we were tr= ying to solve the problems we were interested in rather than the ones that = the user actually cared about. And yes, users do really care about security= but their security concerns are much broader than the ones raised on the c= ypherpunks mailing lists. They are concerned about the control that corpora= tions might have over them much more than governments. They are concerned w= ith the risk of losing the pictures of their kids at 5 years old to ransomw= are.

=
Carl Ellison says th= at the user base of any security protocol halves for each click required to= use it. This led me to ask, 'how can we reduce total user effort' = and not just effort required for security. Today we ask the user to configu= re their email client twice, first to make use of email and again to make e= mail secure (and then we require them to redo the second annually for S/MIM= E).

<= div class=3D"gmail_default" style=3D"font-size:small">The result of this ap= proach is an infrastructure I call the Mathematical Mesh which I would like= IETF participants to consider as a standards track effort, either in part = or in whole.
The goal of = the Mesh is to make computers easier to use by making them more secure. Thi= s is easier than people might imagine. The key here is that every set of in= structions that you write down and give to a human can be written as code a= nd given to a suitably authorized computer system.

The phrase suitably authorized is key here, often= the reason manual intervention=C2=A0is required to=C2=A0configure systems requires is = that certain system privileges are needed.

Like BitCoin, the Mesh extends the traditional cryptograp= hic repertoire. While all of the cryptographic techniques used in the Mesh = are well established in the academic field, this is the first time anyone h= as (to my knowledge) proposed making use of them in an open standard.
=

The Mesh is designed to make f= ull use of the capabilities of modern computer systems: It is assumed that = every user has access to a machine with at least the capability of a Raspbe= rry Pi Zero for purposes of configuring an managing devices. Connection and= use of constrained devices of Arduino Mega class and above is also support= ed by offloading certain security functions to a trusted gateway.

I am posting this here to solicit = opinions as to whether I should bring some or all of this work to the IETF = or if I should take it to other forums.

The drafts are available in plaintext or HTML format. Since = some of the drafts make extensive use of mathematical notations, I recommen= d reading them in the HTML format.

HTML:
http://mathmesh.com/Documents/draft-hallambaker= -mesh-architecture..html=C2=A0=C2=A0
http://mathmesh.com/Document= s/draft-hallambaker-mesh-udf.html=C2=A0
http://mathmesh.com/Document= s/draft-hallambaker-mesh-dare.html=C2=A0
http://mathmesh.com/Docum= ents/draft-hallambaker-mesh-schema.html=C2=A0=C2=A0
http://m= athmesh.com/Documents/draft-hallambaker-mesh-protocol.html=C2=A0=C2=A0<= br>
http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-cry= ptography.html=C2=A0=C2=A0

Plaintext:
https://datatracker.ietf.org/doc/draft-hall= ambaker-mesh-architecture/=C2=A0
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/
https://datatracke= r.ietf.org/doc/draft-hallambaker-mesh-dare/
https://datatracker.ietf.org/doc/draft-hallam= baker-mesh-schema/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/
https://datatracker.i= etf.org/doc/draft-hallambaker-mesh-trust/
https://datatracker.ietf.org/doc/draft-ha= llambaker-mesh-cryptography/

=
These drafts are not yet complete as the= example material and schema documentation is still being revised. This wil= l be addressed as the reference code passes the remaining unit tests for ea= ch functional unit. The principle adopted being that it is better to have n= o examples than incorrect ones.

The following drafts are planned but not yet = written:

https://datatracker.ietf.org/doc/draft-halla= mbaker-mesh-constrained/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantu= m/

The reference code is open source and runs in C# under .net Core. = It is currently tested only on the Windows platform but previous versions h= ave run on OSX and Linux.

https://github.com/hallambaker/Mathematical-Mes= h=C2=A0=C2=A0

The code system is also open source. These tools allowe= d me to design, implement and document a code base that is capable of perfo= rming significant portions of the functions of PKIX, S/MIME, Blockchain, SM= TP, IMAP and TLS on my own in a little less than three years.

https://githu= b.com/hallambaker/PHB-Build-Tools=C2=A0=C2=A0
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000004a1e74058721e19e-- From nobody Mon Apr 22 11:27:29 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2D120132; Mon, 22 Apr 2019 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 iS0G9X2AgFtq; Mon, 22 Apr 2019 11:27:21 -0700 (PDT) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (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 CF0F0120092; Mon, 22 Apr 2019 11:27:20 -0700 (PDT) Received: by mail-oi1-f171.google.com with SMTP id v84so9197190oif.4; Mon, 22 Apr 2019 11:27:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=giuTtSn7aiziD3JLmH15ClqdXDHXNpqDqkHaC/CXDNs=; b=l3wXmeCZg0Yya4HWNmQxRFFJ+PNF5vFHgYXNp07pH4PgknCU9sBzlR1XFkw79nhBuK 4h+X+CZxFBxTyMmnxZf3jl39fs/y2dJPCd6ibHyrRStE4qT3rI2oi3b49fvepEULmxlp lucB9rp33P+0m3pQAA09FirBGTwETIyg9/8qV5/1K6rasq+s6YABvQ8xfRr6NSqTEdM6 0vJW0a3kI4iTJZz8HFPVRO6R3fxpmjLe8oaFTDFX+Kc/jIznKIXQW5CYnHMsy7ZWL7Nc 3nQlAmR9ZcBGgrV5J8AyGVbxP4WHGVkuwcNsOwQT9408uKENZSzYC16Yb0MEppxdWq9K L4Zw== X-Gm-Message-State: APjAAAWI7RS/ftkd8gZMfX3iYGwm+VVAuLceo89aFIzkZN97+sD2O8xZ aPSVgXT1mIQ1KMAEgYjn89b+9Bf8VFccnC1ZkFwGoRaW X-Google-Smtp-Source: APXvYqyIzQwNedxPpax33enU39mxqYWbF2+PijyXCntvXJK2QklwhX4buGrN5qlGWk6VEGzRkWTx0zWSEXi6mxU3o0o= X-Received: by 2002:aca:b8c4:: with SMTP id i187mr11153733oif.6.1555957639689; Mon, 22 Apr 2019 11:27:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 14:27:08 -0400 Message-ID: To: Richard Barnes Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000066390a0587229e91" Archived-At: Subject: Re: [Secdispatch] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:27:22 -0000 --00000000000066390a0587229e91 Content-Type: text/plain; charset="UTF-8" At this stage, I am trying to get people to actually look at the documents before I start actively marketing this scheme. I am currently in the process of spinning up my own company. When I worked as a Principal Scientist for two major Internet concerns for a total of over 20 years, one of my main job functions was identifying interesting technologies. The Mesh makes use of a unique set of cryptographic capabilities. It is the first time to my knowledge that anyone has explored the potential of Torben Pedersen or Matt Blaze's work. If people would like this to be an open system based on non-proprietary standards, this is your chance. On Mon, Apr 22, 2019 at 1:34 PM Richard Barnes wrote: > Hi Phil, > > Thanks for the note. The IETF typically works on specifications for > interoperability between multiple implementations. Is there more than one > party involved / interested in implementing? > > --Richard > >> >> --00000000000066390a0587229e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At this stage, I am trying to get people to actually look at = the documents before I start actively marketing this scheme.

I am currently in the process of spinni= ng up my own company. When I worked as a Principal Scientist for two major = Internet concerns for a total of over 20 years, one of my main job function= s was identifying interesting technologies.

The Mesh makes use of a unique set of cryptographic ca= pabilities. It is the first time to my knowledge that anyone has explored t= he potential of Torben Pedersen or Matt Blaze's work.

If people would like this to be an open = system based on non-proprietary standards, this is your chance.


On Mon, Apr 22, = 2019 at 1:34 PM Richard Barnes <rlb@ipv.sx> wrote:
Hi Phil,

Thanks for the note.=C2=A0 The IETF typically works o= n specifications for interoperability between multiple implementations.=C2= =A0 Is there more than one party involved / interested in implementing?

--Richard
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
--00000000000066390a0587229e91-- From nobody Mon Apr 22 12:03:15 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1D1120326; Mon, 22 Apr 2019 12:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 i8zgfuOTGLq7; Mon, 22 Apr 2019 12:03:12 -0700 (PDT) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (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 21DF61202CC; Mon, 22 Apr 2019 12:03:11 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9B73D141317; Mon, 22 Apr 2019 19:03:10 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-12-146.trex.outbound.svc.cluster.local [100.96.12.146]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2E038140B68; Mon, 22 Apr 2019 19:03:09 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 22 Apr 2019 19:03:10 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Keen-Abiding: 69dae8b3108e2287_1555959789771_2002372353 X-MC-Loop-Signature: 1555959789771:2258660722 X-MC-Ingress-Time: 1555959789771 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 21C7A7F7E5; Mon, 22 Apr 2019 12:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OETIs7kBvfzi5y mg2E/S4Qn0UXY=; b=l0t6RBrbRZVmpMjqJznnv6Di4BdbkDFaN3eu3rgsLIhiO6 UOSwTO9dRNKWtROtPGQL6eWXjEASx94XswbGGsZy5Mp0liAhRag4pfeEnJEDxfkA DaBaoLFytfUP4j0UlEqDwbgeiCwnFqgZvI/bkw2uUMyxmI0lUPy7HtCB6ciag= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 177B07F7D4; Mon, 22 Apr 2019 12:03:05 -0700 (PDT) Date: Mon, 22 Apr 2019 14:03:03 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, saag@ietf.org Message-ID: <20190422190302.GA3137@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigdduvdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 19:03:14 -0000 Is it fair to characterize this as something of a PGP trust mesh on steroids? If not, how does it differ? (Yes, I do see that your scheme has decentralized device management for individuals, which is a bit of a new thing and very welcome.) Nico -- From nobody Mon Apr 22 12:33:44 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432D2120124; Mon, 22 Apr 2019 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 75fwr7JsmECN; Mon, 22 Apr 2019 12:33:34 -0700 (PDT) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 47B5D120123; Mon, 22 Apr 2019 12:33:34 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id v10so9363415oib.1; Mon, 22 Apr 2019 12:33:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vGnOJfZDvIOCpeXXnimpAv895YNN7/o1N5nVDiI/kBc=; b=sUnXM5uwPZzoTnrwpZl7xhWjai/Plirs1sdUEBnBpXTq5ExiEXfqgDAnxQoXUdFpHY Okn1vsjzBPgteUn1mOZV+uIiHNDm4NEk2Dc49o3LQST0Xie6bmJOTNdGHy5cDs+0ORrp lDaLho+3ViWkhuKDpDiR9iNoGxPyV7h112QuHpuZQWVPy9DHIKfVps1Vde2GH8ivgRZB 5m9s8r8jrUSv7LvBbXVCOtbrXWYrOvBxdEQYK3YLtjJ78t543ea8Dy/I7U05tQBxO7Pk YlrWgpepJD+czAdIGQ8Pe+XYw3YqhkpcFHn/sEA3dTK1UfzM1j3ndk9fSQNX10Dt9jmR AFlw== X-Gm-Message-State: APjAAAXGyXu48UHi1o8E81JOjiLflXFkdrOhDoBanD9E/jIDg3QBmu5D fZrU0QI6zgDRVAJtNotdhwW2/oIqcis/CsBLfmsk81Ig X-Google-Smtp-Source: APXvYqxOhXW8pq7cW8B+4/zwPwvXD1sGCsNyXXKRDAmr+DY9Zh3F1ypTj/DlSJdDvgZSkoDKad97yPtPhM+tEp0JUb8= X-Received: by 2002:aca:b8c4:: with SMTP id i187mr11351077oif.6.1555961613481; Mon, 22 Apr 2019 12:33:33 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: <20190422190302.GA3137@localhost> From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 15:33:22 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000417c1d0587238bad" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 19:33:36 -0000 --000000000000417c1d0587238bad Content-Type: text/plain; charset="UTF-8" On Mon, Apr 22, 2019 at 3:03 PM Nico Williams wrote: > Is it fair to characterize this as something of a PGP trust mesh on > steroids? If not, how does it differ? > > (Yes, I do see that your scheme has decentralized device management for > individuals, which is a bit of a new thing and very welcome.) The objective is to give users the power to control their own security environment. This includes but is not limited to the ability to make use of Web-of-Trust approaches or delegated trust, delegated distrust or a combination of all three which is actually the approach I think works best. The primary focus is enabling real users to manage public key pairs on their devices without being aware that they are doing it. Securely establishing a set of public key pairs on each device and providing a validation path to the user's personal axiom of trust is the main idea here. Because if we achieve that, we are 80% of the way to securing almost any communication pattern. Trust topology is something I think we should be opportunistic on and use every available option. For example: * We meet at an IETF and exchange our master profile fingerprint directly using the QR code exchange. * You meet Alice at another meeting and directly exchange credentials using the QR code exchange. * I add Alice to the GitHub repo for the project based on your recommendation. * I add my personal banker to my account based on an Extended Validation certificate authenticating his bank and an assertion issued by the bank credentialing him as a current employee. Right now, I am doing everything in JSON and the Mesh Assertion infrastructure. It is pretty obvious that some of this is SAML territory. But where should the boundary be and should we make use of the XML SAML binding or switch it to a JSON encoding? I don't know what the right decision is there or have time to think about it. I have only scratched the surface as far as applying the key co-generation and splitting techniques I use. We could use them to distribute TLS certificate key pairs as well. --000000000000417c1d0587238bad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 22, 2019 at 3:03 PM Nico Williams <nico@cryptonector.com> wrote:
Is it fair to characterize this as something of a PGP trust mesh= on
steroids?=C2=A0 If not, how does it differ?

(Yes, I do see that your scheme has decentralized device management for
individuals, which is a bit of a new thing and very welcome.)
<= div>
T= he objective is to give users the power to control their own security envir= onment.=C2=A0=C2=A0

T= his includes but is not limited to the ability to make use of Web-of-Trust = approaches or delegated trust, delegated distrust or a combination of all t= hree which is actually the approach I think works best.


The primary focus is enabling real users to manage pub= lic key pairs on their devices without being aware that they are doing it. = Securely establishing a set of public key pairs on each device and providin= g a validation path to the user's personal axiom of trust is the main i= dea here. Because if we achieve that, we are 80% of the way to securing alm= ost any communication pattern.


Trust topology is something I thi= nk we should be opportunistic on and use every available option. For exampl= e:

* We meet at an = IETF and exchange our master profile fingerprint directly using the QR code= exchange.
* Yo= u meet Alice at another meeting and directly exchange credentials using the= QR code exchange.
* I add Alice to the GitHub repo for the project based on your recommen= dation.
* I add= my personal banker to my account based on an Extended Validation certifica= te authenticating his bank and an assertion issued by the bank credentialin= g him as a current employee.


Right = now, I am doing everything in JSON and the Mesh Assertion infrastructure. I= t is pretty obvious that some of this is SAML territory. But where should t= he boundary be and should we make use of the XML SAML binding or switch it = to a JSON encoding? I don't know what the right decision is there or ha= ve time to think about it.

I have only scratched the surface as far as applying the key co-generatio= n and splitting techniques I use. We could use them to distribute TLS certi= ficate key pairs as well.
--000000000000417c1d0587238bad-- From nobody Mon Apr 22 13:38:31 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44341203AF; Mon, 22 Apr 2019 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 S95WiB6Nsmth; Mon, 22 Apr 2019 13:38:27 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (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 05E311203A3; Mon, 22 Apr 2019 13:38:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E709F5E19C2; Mon, 22 Apr 2019 20:38:23 +0000 (UTC) Received: from pdx1-sub0-mail-a17.g.dreamhost.com (100-96-2-149.trex.outbound.svc.cluster.local [100.96.2.149]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 054285E17DD; Mon, 22 Apr 2019 20:38:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a17.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 22 Apr 2019 20:38:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Battle-Stretch: 3c1105ee7658ad00_1555965503764_1072370635 X-MC-Loop-Signature: 1555965503764:3972106718 X-MC-Ingress-Time: 1555965503763 Received: from pdx1-sub0-mail-a17.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTP id A42297F6CD; Mon, 22 Apr 2019 13:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=94TykgqELZq3nI B6AsLc5rQ+SOw=; b=b9kbsijjNZafTwo7uzO+NHKV9t+5pBxJCQmsueok+/6ysR 9eP5TrLk/bdcdwufYPhHR3MrcR8mVpIRnZHAN8uG+k1eWFuDJ7lN3gvAz1U13YcT VKnPx49mjzh2Mmt1izuPyHYPlc4x5/2RA+t0t5wOru3I9I0pG9FL0O1DK2VAY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 861F07F6EA; Mon, 22 Apr 2019 13:38:16 -0700 (PDT) Date: Mon, 22 Apr 2019 15:38:13 -0500 X-DH-BACKEND: pdx1-sub0-mail-a17 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190422203812.GB3137@localhost> References: <20190422190302.GA3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigddugeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 20:38:30 -0000 On Mon, Apr 22, 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote: > On Mon, Apr 22, 2019 at 3:03 PM Nico Williams wrote: > > Is it fair to characterize this as something of a PGP trust mesh on > > steroids? If not, how does it differ? > > > > (Yes, I do see that your scheme has decentralized device management for > > individuals, which is a bit of a new thing and very welcome.) > > The objective is to give users the power to control their own security > environment. > > This includes but is not limited to the ability to make use of Web-of-Trust > approaches or delegated trust, delegated distrust or a combination of all > three which is actually the approach I think works best. OK, so, all-of-the-above trust? But there's nothing new yet, besides hierarchical[0], and web-of-trust[1], TOFU, and things in between[2] right? Just a new way of doing all-of-the-above? This is not a critique. I think a simple characterization will help. "All of the above on steroids" seems fair. But I do feel that the device management part is separable, even though it's certainly critical for the UX. [0] E.g., PKI, DNSSEC, Kerberos. [1] E.g., PGP. [2] E.g., WebPKI, which isn't exactly hierarchical, and definitely isn't webby as to trust. > The primary focus is enabling real users to manage public key pairs on > their devices without being aware that they are doing it. Securely > establishing a set of public key pairs on each device and providing a > validation path to the user's personal axiom of trust is the main idea > here. Because if we achieve that, we are 80% of the way to securing almost > any communication pattern. Agreed. Vendors will (already do) gladly help you do this within their walled garden, natch. The result is... a bit lame. > Trust topology is something I think we should be opportunistic on and use > every available option. For example: Ah, "opportunistic". TOFU. Sure. > * We meet at an IETF and exchange our master profile fingerprint directly > using the QR code exchange. > * You meet Alice at another meeting and directly exchange credentials using > the QR code exchange. > * I add Alice to the GitHub repo for the project based on your > recommendation. > > * I add my personal banker to my account based on an Extended Validation > certificate authenticating his bank and an assertion issued by the bank > credentialing him as a current employee. OK, so WebPKI, PKI (if we had it, which, well, we do, since DNSSEC is a PKI). > Right now, I am doing everything in JSON and the Mesh Assertion > infrastructure. It is pretty obvious that some of this is SAML territory. > But where should the boundary be and should we make use of the XML SAML > binding or switch it to a JSON encoding? I don't know what the right > decision is there or have time to think about it. It's always tempting to start from scratch... But it's already been done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make the right choice. Nico -- From nobody Mon Apr 22 20:17:28 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB381200FE; Mon, 22 Apr 2019 20:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc1qH7sEUO_J; Mon, 22 Apr 2019 20:17:19 -0700 (PDT) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) (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 D20C7120075; Mon, 22 Apr 2019 20:17:18 -0700 (PDT) Received: by mail-ot1-f67.google.com with SMTP id u15so11498993otq.10; Mon, 22 Apr 2019 20:17:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aEyqpNa6IORQoUWGrmIxPYHkXlkb/e8lfJhtd9Pg8WQ=; b=bEfGt3hHPAosCQ1sOEF5ylSPaQ2SX8Pz0Ta8yjTjtZYgkJFfoKwSWrbuiFqamNBx1v lkU2gXYHBuTKhQTN0aWYpBiHo0TIHsZIG7cpAnb8jJpErlcnRlZaHxLql8S/iII4OlNi iLwCiQjP2nD7Oe3QmULPNojzNX/MGcnjF9h00DMqHAoF4MfIahnJ5c7opMXX4wgHRqqE wnvLsvpGdM2rcrQCKBHT+2COo64ngLErHBAFwhBQFqJkadIxIb86hqPnQE82hRJzutUZ jsGCerU7Akw3zMeY1Vip99FV4qrlS64MWXFXsX8v+gwjg4Sb7p6RgGzW7fHw+SD+VfKv 9lsw== X-Gm-Message-State: APjAAAXHgLBibSwFqZTnncxADj60F6yVIb/1otkbpLTam7HE1x8QFf97 uUGqQE/mQ1ViALpH5H0nlSo7gIIfU0ReosF9b4KuFQ== X-Google-Smtp-Source: APXvYqz6jxPoEYZpulY3FlAhcjQV5dWWtsl7p1rXzhEoWL1l/YBZM11mkOHQ19BjeF1h+ChDXyk6H052Qo+CW6/XhPs= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr14131893oth.150.1555989438056; Mon, 22 Apr 2019 20:17:18 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> <20190422203812.GB3137@localhost> In-Reply-To: <20190422203812.GB3137@localhost> From: Phillip Hallam-Baker Date: Mon, 22 Apr 2019 23:17:07 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000bacd7e05872a05cc" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 03:17:20 -0000 --000000000000bacd7e05872a05cc Content-Type: text/plain; charset="UTF-8" On Mon, Apr 22, 2019 at 4:38 PM Nico Williams wrote: > On Mon, Apr 22, 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote: > > On Mon, Apr 22, 2019 at 3:03 PM Nico Williams > wrote: > > > Is it fair to characterize this as something of a PGP trust mesh on > > > steroids? If not, how does it differ? > > > > > > (Yes, I do see that your scheme has decentralized device management for > > > individuals, which is a bit of a new thing and very welcome.) > > > > The objective is to give users the power to control their own security > > environment. > > > > This includes but is not limited to the ability to make use of > Web-of-Trust > > approaches or delegated trust, delegated distrust or a combination of all > > three which is actually the approach I think works best. > > OK, so, all-of-the-above trust? > > But there's nothing new yet, besides hierarchical[0], and > web-of-trust[1], TOFU, and things in between[2] right? > > Just a new way of doing all-of-the-above? > > This is not a critique. I think a simple characterization will help. > > "All of the above on steroids" seems fair. > The objective here is to put the user in control and not try to force any particular model on them. One distinction I do feel very strongly on is that the configuration of trust relationships between devices belonging to the same entity is a completely different issue to the problem of trust between entities. Now I accept that there are some weasel words there, 'belonging' and 'entity'. But I still think there are important differences. Lets call the first problem the 'device-trust' problem and the second the 'inter-trust' problem Why I buy a new device I am adding it to my network which is in turn connected to the Internet. So the decision to trust the device is mine and mine alone. I am fairly certain I don't want to outsource the decision to grant trust. But I might under certain circumstances delegate the decision to distrust. So Symantec might tell me that my toaster is trying to kill me or the blender is trading crypto currencies and shut them down on my behalf. > But I do feel that the device management part is separable, even though > it's certainly critical for the UX. > I have no objections to an a-la-carte approach. The device management part is certainly the core here. The basic concept is that let us say that the device ships from the factory with a set of crypto keys burned in at the very chip level, cannot ever be altered or extracted. The protocols I have developed allow those keys to be used in conjunction with an overlay set of keys provided by the administration device. The net effect is that we get all the advantages of keys that are installed during manufacture and all the advantages of application generated keys. The combined key is secure against external attack if either of the key contributions is. The manufacturer key does not provide a backdoor capability unless the user generates a weak overlay key set. > > Right now, I am doing everything in JSON and the Mesh Assertion > > infrastructure. It is pretty obvious that some of this is SAML territory. > > But where should the boundary be and should we make use of the XML SAML > > binding or switch it to a JSON encoding? I don't know what the right > > decision is there or have time to think about it. > > It's always tempting to start from scratch... But it's already been > done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make > the right choice. > Naturally and this is one of the reasons I have steered clear of the inter-trust problem because it has been the part of the problem we like to beat on most. --000000000000bacd7e05872a05cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 22, 2019 at 4:38 PM Nico Williams <<= a href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com> wrote= :
On Mon, Apr 22= , 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote:
> On Mon, Apr 22, 2019 at 3:03 PM Nico Williams <nico@cryptonector.com> wrote:=
> > Is it fair to characterize this as something of a PGP trust mesh = on
> > steroids?=C2=A0 If not, how does it differ?
> >
> > (Yes, I do see that your scheme has decentralized device manageme= nt for
> > individuals, which is a bit of a new thing and very welcome.)
>
> The objective is to give users the power to control their own security=
> environment.
>
> This includes but is not limited to the ability to make use of Web-of-= Trust
> approaches or delegated trust, delegated distrust or a combination of = all
> three which is actually the approach I think works best.

OK, so, all-of-the-above trust?

But there's nothing new yet, besides hierarchical[0], and
web-of-trust[1], TOFU, and things in between[2] right?

Just a new way of doing all-of-the-above?

This is not a critique.=C2=A0 I think a simple characterization will help.<= br>
"All of the above on steroids" seems fair.
<= br>
The ob= jective here is to put the user in control and not try to force any particu= lar model on them. One distinction I do feel very strongly on is that the c= onfiguration of trust relationships between devices belonging to the same e= ntity is a completely different issue to the problem of trust between entit= ies.

=
Now I accept that th= ere are some weasel words there, 'belonging' and 'entity'. = But I still think there are important differences. Lets call the first prob= lem the 'device-trust'=C2=A0 problem and the second the 'inter-= trust' problem

Why I = buy a new device I am adding it to my network which is in turn connected to= the Internet.
=
So the dec= ision to trust the device is mine and mine alone. I am fairly certain I don= 't want to outsource the decision to grant trust. But I might under cer= tain circumstances delegate the decision to distrust. So Symantec might tel= l me that my toaster is trying to kill me or the blender is trading crypto = currencies and shut them down on my behalf.

=C2=A0
<= /div>
But I do feel that the device management part is separable, even though
it's certainly critical for the UX.

I have no objections to = an a-la-carte approach. The device management part is certainly the core he= re.

<= div class=3D"gmail_default" style=3D"font-size:small">The basic concept is = that let us say that the device ships from the factory with a set of crypto= keys burned in at the very chip level, cannot ever be altered or extracted= . The protocols I have developed allow those keys to be used in conjunction= with an overlay set of keys provided by the administration device.

The net effect is that we get = all the advantages of keys that are installed during manufacture and all th= e advantages of application generated keys. The combined key is secure agai= nst external attack if either of the key contributions is. The manufacturer= key does not provide a backdoor capability unless the user generates a wea= k overlay key set.

=C2=A0
> Right now, I am doing everything in J= SON and the Mesh Assertion
> infrastructure. It is pretty obvious that some of this is SAML territo= ry.
> But where should the boundary be and should we make use of the XML SAM= L
> binding or switch it to a JSON encoding? I don't know what the rig= ht
> decision is there or have time to think about it.

It's always tempting to start from scratch...=C2=A0 But it's alread= y been
done via OAuth/JWT.=C2=A0 Don't feel bad for not using SAML/XML.=C2=A0 = Just make
the right choice.

Naturally and this is one of the reasons I hav= e steered clear of the inter-trust problem because it has been the part of = the problem we like to beat on most.
--000000000000bacd7e05872a05cc-- From nobody Mon Apr 22 20:49:29 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412CC1202E9; Mon, 22 Apr 2019 20:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 tw8k-3TCbxIJ; Mon, 22 Apr 2019 20:49:25 -0700 (PDT) Received: from eastern.maple.relay.mailchannels.net (eastern.maple.relay.mailchannels.net [23.83.214.55]) (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 08F081200C3; Mon, 22 Apr 2019 20:49:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3476E3E4CA4; Tue, 23 Apr 2019 03:49:23 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B33993E52FC; Tue, 23 Apr 2019 03:49:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 23 Apr 2019 03:49:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Scare-Juvenile: 17cc082d7fd0fc5f_1555991363017_3952312522 X-MC-Loop-Signature: 1555991363017:3502328466 X-MC-Ingress-Time: 1555991363016 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id 5AAF382663; Mon, 22 Apr 2019 20:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BrWw6SydtVwDsp hO7rCO2V/JhVc=; b=T7BDc1FhAYKnSa5kBxhHbGNaRw/v3+qTrdRwCYDr37PX2e 9rG1t3PCCQzP2mwBz0FwrhiL2FVB9dFh9U//YziPFUxHPzvCYiUTUf923Uqw/jMr Q1ItMQ01yevPgWmgXCH9TbEy2pMH2mxM8yMGaqOhY7q1A5uP6IDPD5GM60iMs= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 15DAB82661; Mon, 22 Apr 2019 20:49:20 -0700 (PDT) Date: Mon, 22 Apr 2019 22:49:18 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190423034917.GF3137@localhost> References: <20190422190302.GA3137@localhost> <20190422203812.GB3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdeihecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 03:49:27 -0000 On Mon, Apr 22, 2019 at 11:17:07PM -0400, Phillip Hallam-Baker wrote: > [...]. One distinction I do feel very strongly on is > that the configuration of trust relationships between devices belonging to > the same entity is a completely different issue to the problem of trust > between entities. So much so that it's even separable from the rest. When it comes to one's own devices (for some value of "own"), the introducer problem is trivially solved: one is the introduced, and assuming physical access, the rest is trivial. Indeed, smartphone vendors have even solved that -- within their walled gardens anyways. Getting an interoperable protocol for device key management widely implemented would be a real coup. > > But I do feel that the device management part is separable, even though > > it's certainly critical for the UX. > > I have no objections to an a-la-carte approach. The device management part > is certainly the core here. I'm not asking for it to be separated, just noting that it is separable. Again, I'm looking for a pithy description of the proposal. It's now "all ove the above as to trust" + "open device key management". Anything else? > > > Right now, I am doing everything in JSON and the Mesh Assertion > > > infrastructure. It is pretty obvious that some of this is SAML territory. > > > But where should the boundary be and should we make use of the XML SAML > > > binding or switch it to a JSON encoding? I don't know what the right > > > decision is there or have time to think about it. > > > > It's always tempting to start from scratch... But it's already been > > done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make > > the right choice. > > Naturally and this is one of the reasons I have steered clear of the > inter-trust problem because it has been the part of the problem we like to > beat on most. On the other hand, to follow an all-of-the-above path means interoperating with existing protocols wherever that helps. For example, there's no need for a replacement for PGP or S/MIME. What is needed is a way to simplify introductions and key exchange, to get it down to scanning a QR code and pressing a button. Ditto TOFU (though that's trickier, naturally). Ditto WebPKI. I've this idea that DANE stapling in TLS could be used to provide not just server authentication to clients, but also user authentication to servers, using client EE certificates with rfc822Name SANs and DANE to authenticate the domainname of a client certificate's rfc822Name SAN(s). (Many don't trust the DNSSEC root any more than others trust WebPKI, but for most users, anything is better than nothing.) The varying levels of trust will surely complicate the UI somewhat. At least power users will want to be able to see some indication of trust strength / how an introduction happened. Nico -- From nobody Mon Apr 22 21:29:48 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6B1200D7; Mon, 22 Apr 2019 21:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 G9zn8dWodCXo; Mon, 22 Apr 2019 21:29:37 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (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 353D8120021; Mon, 22 Apr 2019 21:29:37 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 501A612570E; Tue, 23 Apr 2019 04:29:36 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (unknown [100.96.20.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 05262125299; Tue, 23 Apr 2019 04:29:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 23 Apr 2019 04:29:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Suffer-Grain: 2473b2da4b923d79_1555993776158_2600418844 X-MC-Loop-Signature: 1555993776158:2271316949 X-MC-Ingress-Time: 1555993776158 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id BA73C8266D; Mon, 22 Apr 2019 21:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=X6qGsmU0sltQY9 7HudLFbMxB87Y=; b=Ay7woIW5hiPREZh7j3bn/2kNb8uebQpMO9rBMk/RKuLWIN sWMRlyEmKIFJ+kOlPVtbaZOawuDwlcnmK+TgpetwteJOJroCP7uJrWD9zoHSCwp8 UiklHiixr8TRhAir5/WqR5gWOMNpVf9cmg6WgF0HHFgb1XyzUFYj8oaFeeUfw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C590A8266B; Mon, 22 Apr 2019 21:29:34 -0700 (PDT) Date: Mon, 22 Apr 2019 23:29:32 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190423042931.GH3137@localhost> References: <20190422190302.GA3137@localhost> <20190422203812.GB3137@localhost> <20190423034917.GF3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190423034917.GF3137@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdejfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:29:40 -0000 On Mon, Apr 22, 2019 at 10:49:18PM -0500, Nico Williams wrote: > I've this idea that DANE stapling in TLS could be used to provide not > just server authentication to clients, but also user authentication to > servers, using client EE certificates with rfc822Name SANs and DANE to > authenticate the domainname of a client certificate's rfc822Name SAN(s). Ugh, I meant that DANE would authenticate the client cert's issuer, identified by the domainname of the rfc822Name SAN. From nobody Tue Apr 23 05:16:50 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905781200D6 for ; Tue, 23 Apr 2019 05:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 0zVuHa7YurQg for ; Tue, 23 Apr 2019 05:16:41 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 AE31A1200EF for ; Tue, 23 Apr 2019 05:16:36 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id t79so3721365ywc.7 for ; Tue, 23 Apr 2019 05:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ABVFw89Elv3WudEC/XI6Fq/nBOWRAPNx8FGz4fzi3Ew=; b=EueJulQNvkRU8XqlR4kMgCByMln/zmlehQVp1/AnRzz55thtOvjit/iXyGW5Yrsig0 IkP8XR8T1+fhbYKDV6UTm2/RofPhXvNwomPNlpFTioas4I1SDNzZ8SD9+ntFj0bkB5tv gZBuvP5jUo5m6XIdA3ibLZE7b93P0It2aYdp1IlrHTT2McyRWq7/zfP6V2CgYrE326GU RxStdX0sgixAZkquBkY2oObPtIU/gBdUM6qpjzoQmsgiV56wOdawxGXmon0D5A7xTeNu c+5oESkQnjxYAs61gQW8AYkKOlFD6KZLmcUhmYgAQIxiJ7tHLCiyK8pgPbEAtIA07tFO kdyw== 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=ABVFw89Elv3WudEC/XI6Fq/nBOWRAPNx8FGz4fzi3Ew=; b=tFgxIfqqICbcOV3URsj4Mai1ZHOgjuDPETYSEnxcmlls7vk5Z3dP03w6NMcZ/usxIo sSDW2eHwX+92IiZ/z7EaVZdt9jfMgpISrQVd8+fh72pniQ1psFraiQvu7VJ7R86QG8+M lmjyqniRy5/rvx0JVHXSh1L91bSv2gVl+BxKbTLYAGUCIdVWjht7hzvkIRVxrcJHFqq5 94I2As5sr6dIQ8YaatN9zN42KH/gYFYaPzXQ+xFzj1JuD+imbXgLxqJT6IhPnzdLJ2zr wafw2717X4h8i4VMnfdrhvecI15YNfbalctyP9rFm5RPN9vJvR7A7AuH3eG7mloo1F2D MOOQ== X-Gm-Message-State: APjAAAUvcQMU6MZCllx0EUYcp75UVASqptzPfvdzKnLv5PIipUlGY7lk ZeEsvhpi5npXvn33+bjMUErTlxS0Tu04+ZjkPl2YZQ== X-Google-Smtp-Source: APXvYqzcD9UHlqR9qNj6vR6f5vlDxVmO/1/O65TTIz2A28d0G4r1mwV6MN3rHZ492NDp6DgoM1DGZbKJn8Z4yGWxArY= X-Received: by 2002:a81:7c55:: with SMTP id x82mr20442279ywc.488.1556021795621; Tue, 23 Apr 2019 05:16:35 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Tue, 23 Apr 2019 13:16:23 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Nico Williams , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000647f880587318e0f" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 12:16:43 -0000 --000000000000647f880587318e0f Content-Type: text/plain; charset="UTF-8" On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker wrote: > The primary focus is enabling real users to manage public key pairs on > their devices without being aware that they are doing it. Securely > establishing a set of public key pairs on each device and providing a > validation path to the user's personal axiom of trust is the main idea > here. Because if we achieve that, we are 80% of the way to securing almost > any communication pattern. > Where is the user testing for this? BTW, seems to me if users are not aware that they are doing it, they will also not be aware when they are not doing it. That doesn't seem like a path to security to me. -- I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w. #VerifyAllTheThings. *https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22 * --000000000000647f880587318e0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 22 Apr 2019 at 20:33, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:
The primary focus is enabling real users to manage public key pairs o= n their devices without being aware that they are doing it. Securely establ= ishing a set of public key pairs on each device and providing a validation = path to the user's personal axiom of trust is the main idea here. Becau= se if we achieve that, we are 80% of the way to securing almost any communi= cation pattern.

Wher= e is the user testing for this? BTW, seems to me if users are not aware tha= t they are doing it, they will also not be aware when they are not doing it= . That doesn't seem like a path to security to me.

=
--
I am hiring! Formal methods, UX, management, SWE ... ve= rified s/w and h/w. #VerifyAllTheThings.

=
--000000000000647f880587318e0f-- From nobody Tue Apr 23 13:22:37 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F313F12013D for ; Tue, 23 Apr 2019 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75IRZUff7cpJ for ; Tue, 23 Apr 2019 13:22:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2813A120344 for ; Tue, 23 Apr 2019 13:22:31 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id D51CB1F457 for ; Tue, 23 Apr 2019 20:22:29 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B8A5E3B51; Tue, 23 Apr 2019 16:14:47 -0400 (EDT) From: Michael Richardson To: secdispatch@ietf.org In-reply-to: References: Comments: In-reply-to Phillip Hallam-Baker message dated "Mon, 22 Apr 2019 12:58:11 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 23 Apr 2019 16:14:47 -0400 Message-ID: <31215.1556050487@dooku.sandelman.ca> Archived-At: Subject: Re: [Secdispatch] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 20:22:34 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have been reading Phill's work off and on as he has progressed over a few years. I think that Richard Barnes' question, "who will implement this" is relevant, but I prefer not to take it too strongly at this point. We have published many things that seemed to have multi-vendor support, whi= ch went nowhere, and some things that are uni-vendor (TACACS..) which are wide= ly used.=20 BOF's attempt to establish such things, and at this point, I don't think it is time for an IETF BOF yet. Often things happen in the open source space and by the time it's clear that it is popular, serious protocol mistakes have occured. For instance, the Matrix system had a version issue early on, and clearly would have benefitt= ed From=20having an open specification around it, and it probably could have benefitting (maybe it is...) from our MLS work.=20 https://lwn.net/Articles/779331/ (google found me this, while I was searching for this article. Looks like implementation not specification issue https://thehackernews.com/2019/04/france-Tchap-secure-messenger.html Here are the directions (not mutually exclusive) that I suggest we consider: 1) an IRTF group. (We did this with HIP for instance) 2) publish some of the foundational documents as AD sponsor 3) thank PHB for his work, ask him to do an IAB plenary talk on it, and update us in 18 months. 4) Informational via the ISE.=20=20=20 Having said this, I want to use the udf: mechanism to avoid sending large IDevIDs across constrained networks (whether with DTLS or EDHOC). I'm sure that I can cook up something else, but it won't be as general. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAly/cjcACgkQlUzhVv38 QpAB1wf+KFzscpQogmYoTRdTUCZjpfK2Liy7DtciuBdurKOa8c6xiyHdbMr5Fape rMNLjpN95hciuGSyK6vR88UqQ4/WbystI+lBC1dPK8VKSwXiRE6jxoo0U+D16aqw 5w1TMKT1LaA03geImFEozm1k/mKo4FfOEwa6WGoeBLHX6N7e0VGXvtzBu6g8RXte CxqYEUSBDycWAWrikVDjAXnnxWTBx7g3hbHWYFZPC5To5PZMvk7qO4/v577E87VE VWLivqSLdEUJRvVpuC8F35PboN1B8ZM5+HzYwUkMVoaAIcR5AodZsBwvJAgHbGZb QIhcNpEz0upiJdkn6PEMFv8cLTA2BA== =ZBAh -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 23 14:23:13 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2812038E; Tue, 23 Apr 2019 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 g3zE3CHuMrGY; Tue, 23 Apr 2019 14:23:04 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.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 2C84512038D; Tue, 23 Apr 2019 14:23:04 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id t8so14205932otp.7; Tue, 23 Apr 2019 14:23:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l0lnV4/b3RKKabkgl1MOZEkGE0qfz/+toe0t4rRON24=; b=O2ijX6+RzC3rT22AD8ucUTmK6qTjbFqZ9fTdGyCxI81oLgfrtklc42BMJyNc/BElgy Nxs/Lx8LGqXZMDL7neAcHJjpjar9Lg1Wwhyg8uNFGL0bg1R0hLcP2LLs7ZvHjixDa3do ZOtSk53he/BGNa2N/9FlHQaB4+eekU5sCnv5to4MuLxhRsvP+8h0kj2BDxq13SF7eQgS himO7xuXyJ2WUeb/z7Vn3jHO5LTFjul4DYWNuTGoPQg7UICSWHnbjcCqpFNk1dYp/0PZ 7SQgp1KsoL52nLrlt1gczU941p1BdaP2h+UWxNNvbt3BdbgELy2FhLG1L86vkSLkBi0Y eJPw== X-Gm-Message-State: APjAAAUFXZexjwL/DoZc2NZcTPrdUnqNyxUpjp94xq3L/lN934sAIcWk To+5TyHO2+Ts8qEJOefEaQSASKvTwcyi18hM5m8= X-Google-Smtp-Source: APXvYqxGlLB+4L4bKOc3yxSxpOCnCageSJvIfUMITMzEbj8YvRL9v8Lq74hWbFM0Qi+6mFpzfFGB/NGLje4Arj615Ps= X-Received: by 2002:a05:6830:1017:: with SMTP id a23mr17803530otp.120.1556054583391; Tue, 23 Apr 2019 14:23:03 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 23 Apr 2019 17:22:52 -0400 Message-ID: To: Ben Laurie Cc: Nico Williams , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000b1bce10587393013" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 21:23:06 -0000 --000000000000b1bce10587393013 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie wrote: > > > On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker > wrote: > >> The primary focus is enabling real users to manage public key pairs on >> their devices without being aware that they are doing it. Securely >> establishing a set of public key pairs on each device and providing a >> validation path to the user's personal axiom of trust is the main idea >> here. Because if we achieve that, we are 80% of the way to securing almost >> any communication pattern. >> > > Where is the user testing for this? BTW, seems to me if users are not > aware that they are doing it, they will also not be aware when they are not > doing it. That doesn't seem like a path to security to me. > Please make that point to the Chrome team who are busy stripping out the security indicators so users don't know if they are on a secure site or not. I have done extensive user testing and come to the conclusion that almost none of it gives useful results. Most 'usability' testing methodology is designed to enable sales. So in 1980 when they started this, Apple was really interested in how to make the first 20 minutes of use as easy and productive a possible because that is the length of a typical sales session. What concerns me is how people behave in normal use when faced with an attack. The usability people do tests that tell them the security indicators are useless and strip them out so the user has no information to tell them whether something is secure or not. And not just Google's usability people, they all want to make the system easier to use by removing security. If you set up the test to look at people's behavior over short time intervals you will get a certain result. You also get that same result if you keep changing the security indicator. There are two concerns that must be addressed if a system is going to be usably secure: 1) The user must not be required to think about security when they are focused on their tasks. 2) The user must have the information they need to understand if their security concerns have been met. There are currently three device connection protocols, all provide a work factor of 2^120 or better. If we are using QR codes to connect devices, we can transmit the necessary information without the user needing to notice that is what we are doing. Otherwise, there are many existing protocols that make comparison of 15-30 character base 32 encoded strings as the basis for mutual authentication and these have proved effective and acceptable. --000000000000b1bce10587393013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <benl@google.com> wrote:


On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker <phill@hallambaker.com&g= t; wrote:
The= primary focus is enabling real users to manage public key pairs on their d= evices without being aware that they are doing it. Securely establishing a = set of public key pairs on each device and providing a validation path to t= he user's personal axiom of trust is the main idea here. Because if we = achieve that, we are 80% of the way to securing almost any communication pa= ttern.
<= br>
Where is the user testing for this? BTW, seems to me if users= are not aware that they are doing it, they will also not be aware when the= y are not doing it. That doesn't seem like a path to security to me.

Please make that point to the Chrome team who are bu= sy stripping out the security indicators so users don't know if they ar= e on a secure site or not.=C2=A0

I have done extensive user testing and come to the conclusion that = almost none of it gives useful results. Most 'usability' testing me= thodology is designed to enable sales. So in 1980 when they started this, A= pple was really interested in how to make the first 20 minutes of use as ea= sy and productive a possible because that is the length of a typical sales = session. What concerns me is how people behave in normal use when faced wit= h an attack.
The usabilit= y people do tests that tell them the security indicators are useless and st= rip them out so the user has no information to tell them whether something = is secure or not. And not just Google's usability people, they all want= to make the system easier to use by removing security. If you set up the t= est to look at people's behavior over short time intervals you will get= a certain result. You also get that same result if you keep changing the s= ecurity indicator.

There = are two concerns that must be addressed if a system is going to be usably s= ecure:

1) The user must n= ot be required to think about security when they are focused on their tasks= .
2) The user m= ust have the information they need to understand if their security concerns= have been met.

There are= currently three device connection protocols, all provide a work factor of = 2^120 or better.

If we ar= e using QR codes to connect devices, we can transmit the necessary informat= ion without the user needing to notice that is what we are doing. Otherwise= , there are many existing protocols that make comparison of 15-30 character= base 32 encoded strings as the basis for mutual authentication and these h= ave proved effective and acceptable.

--000000000000b1bce10587393013-- From nobody Wed Apr 24 01:53:24 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA611202AB; Wed, 24 Apr 2019 01:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1bVh-cm8g4G; Wed, 24 Apr 2019 01:53:13 -0700 (PDT) Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 83A1A120242; Wed, 24 Apr 2019 01:53:13 -0700 (PDT) Received: by mail-qk1-f175.google.com with SMTP id m137so6658742qke.3; Wed, 24 Apr 2019 01:53:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9wxstN3a8zUR+X9QIslPu+2ElNc1YUs2NBndJn0kRwE=; b=NkRZwZBGbrg5r/hquLUOxev+DSrJ9ZOHmvSQ0KILf2gRFL5CqkWu5GY0cgvpI9MWni pLa0lYTpVMnV0t3GNE4EM2xlmvxIjMf3ykMEBNTZ3tbBWEt9bilOQg9FOYadHDco8XVS /FakmrhWjmqFNA1uL2iVs0T7QsqFiibdEFjRlbUJlna90YNqEcbLxKS53v85OeO+Kadu kE0aja4idnl/EoWV6xZbqZeQCsLoQ3BbaRuTfk7+QjluODqRcMQ8aL05KVhxP+q7Uja1 /cwFfsC1JPYfL8XDyHjg4iH38BUf50iIo50AUTFhiee1iaNHHF0tQUH+dfP8ObBpiMcD U92w== X-Gm-Message-State: APjAAAVrHO55ZbyIAiQ5SzYR8YhmdGUU57TAXZJtqp+K3668SQB8w9UT 9hQo64k69SYCLyNwchxjsKFqRHNgfp2FGYzs9yA= X-Google-Smtp-Source: APXvYqzqN890hnOZQypWFXsxIPetadJXgUBR42MH5wgYsJjEgJ19Q9JiGRJWXv9/eG7vBBt7uKEypqC/6j+8HOc4r/s= X-Received: by 2002:a37:63cf:: with SMTP id x198mr16961396qkb.353.1556095992450; Wed, 24 Apr 2019 01:53:12 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Wed, 24 Apr 2019 09:53:01 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ddd5df058742d43c" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 08:53:16 -0000 --000000000000ddd5df058742d43c Content-Type: text/plain; charset="UTF-8" On Tue, 23 Apr 2019 at 22:23, Phillip Hallam-Baker wrote: > > > On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie wrote: > >> >> >> On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker >> wrote: >> >>> The primary focus is enabling real users to manage public key pairs on >>> their devices without being aware that they are doing it. Securely >>> establishing a set of public key pairs on each device and providing a >>> validation path to the user's personal axiom of trust is the main idea >>> here. Because if we achieve that, we are 80% of the way to securing almost >>> any communication pattern. >>> >> >> Where is the user testing for this? BTW, seems to me if users are not >> aware that they are doing it, they will also not be aware when they are not >> doing it. That doesn't seem like a path to security to me. >> > > Please make that point to the Chrome team who are busy stripping out the > security indicators so users don't know if they are on a secure site or > not. > That is not what is happening. Chrome is switching from showing positive to negative indicators. > > I have done extensive user testing and come to the conclusion that almost > none of it gives useful results. Most 'usability' testing methodology is > designed to enable sales. So in 1980 when they started this, Apple was > really interested in how to make the first 20 minutes of use as easy and > productive a possible because that is the length of a typical sales > session. What concerns me is how people behave in normal use when faced > with an attack. > Indeed. > > The usability people do tests that tell them the security indicators are > useless and strip them out so the user has no information to tell them > whether something is secure or not. > Incorrect. > And not just Google's usability people, they all want to make the system > easier to use by removing security. > Also incorrect. > If you set up the test to look at people's behavior over short time > intervals you will get a certain result. You also get that same result if > you keep changing the security indicator. > > There are two concerns that must be addressed if a system is going to be > usably secure: > > 1) The user must not be required to think about security when they are > focused on their tasks.. > 2) The user must have the information they need to understand if their > security concerns have been met. > I agree with both of these points. I have no idea why you think you can get to this state without doing user testing. > > There are currently three device connection protocols, all provide a work > factor of 2^120 or better. > > If we are using QR codes to connect devices, we can transmit the necessary > information without the user needing to notice that is what we are doing. > Otherwise, there are many existing protocols that make comparison of 15-30 > character base 32 encoded strings as the basis for mutual authentication > and these have proved effective and acceptable. > Oh really? Evidence? --000000000000ddd5df058742d43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 23 Apr 2019 at 22:23, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:

<= /div>

On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <benl@google.com> wrote:


On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker <phill@hallambaker.com>= ; wrote:
The pr= imary focus is enabling real users to manage public key pairs on their devi= ces without being aware that they are doing it. Securely establishing a set= of public key pairs on each device and providing a validation path to the = user's personal axiom of trust is the main idea here. Because if we ach= ieve that, we are 80% of the way to securing almost any communication patte= rn.
<= /div>

Where is the user testing for this? B= TW, seems to me if users are not aware that they are doing it, they will al= so not be aware when they are not doing it. That doesn't seem like a pa= th to security to me.

Please make that point to the Chrome team who are bu= sy stripping out the security indicators so users don't know if they ar= e on a secure site or not.=C2=A0

That is not what is happening. Chrome is switching from showing pos= itive to negative indicators.
=C2=A0

I have = done extensive user testing and come to the conclusion that almost none of = it gives useful results. Most 'usability' testing methodology is de= signed to enable sales. So in 1980 when they started this, Apple was really= interested in how to make the first 20 minutes of use as easy and producti= ve a possible because that is the length of a typical sales session. What c= oncerns me is how people behave in normal use when faced with an attack.

Indeed.
=C2=A0

The usability people do tests that tell them the secur= ity indicators are useless and strip them out so the user has no informatio= n to tell them whether something is secure or not.

Incorrect.
=C2=A0
And not just Google's usability peop= le, they all want to make the system easier to use by removing security.

Also incorrect.
= =C2=A0
If you set u= p the test to look at people's behavior over short time intervals you w= ill get a certain result. You also get that same result if you keep changin= g the security indicator.

There are two concerns that must be addressed i= f a system is going to be usably secure:

1) The user must not be required= to think about security when they are focused on their tasks..=C2=A0
=
=
= 2) The user must have the information they need to understand if their secu= rity concerns have been met.

<= div>I agree with both of these points. I have no idea why you think you can= get to this state without doing user testing.
=C2=A0

There are currently three device connection protocols, all provid= e a work factor of 2^120 or better.
If we are using QR codes to connect d= evices, we can transmit the necessary information without the user needing = to notice that is what we are doing. Otherwise, there are many existing pro= tocols that make comparison of 15-30 character base 32 encoded strings as t= he basis for mutual authentication and these have proved effective and acce= ptable.

Oh really? Eviden= ce?

--000000000000ddd5df058742d43c-- From nobody Wed Apr 24 09:47:24 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E55120321; Wed, 24 Apr 2019 09:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 CLlCEQE6cUne; Wed, 24 Apr 2019 09:47:13 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.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 E061B12024A; Wed, 24 Apr 2019 09:47:12 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id d24so14024408otl.11; Wed, 24 Apr 2019 09:47:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uLDyotKJNNgcq5CTRgRhsvrmNKLr1soVVzFSzcm56BQ=; b=TmSqVLZY0s2HZkNs/ElfbGYIQNJbvhaO+4X3rHBkNbAtldAyPBjuEf9dSOzt5B8fUP 4cTo6e6ZSGnA6ZgfWPiNT7hzdHEVVoTDayXx/Im4L9MW44yuVORn8STtv0z4Bb88waBM h8UC+em+II+wBmdeqG5ywZUvOmMWDKOZYmWbI78NVFAoMz4kfyHReXC+E6ZciCITsKAm 21jRPaCJ4UsynHJeIFden9wIDkPVLqwAJvICUShuqrN2yRYAti6SQ1Vd8nXqu6Xq4Qoh QyJ1CCC2lzrVYb/mzRcZbRuQer/nSIzMVod8fqg9VOj9uzc/u0kzVhaTNqAXGhE3W3cT 1LEQ== X-Gm-Message-State: APjAAAUTv2o2XYMDUwwU3Q3DekyuOYAvTrManEt59/dzrA6EKWL7mMrS J4ZMak1IGvinlnLnj+iYufzKi5mGFG8gCsJl4ZE= X-Google-Smtp-Source: APXvYqx6eBQaFonVy+zK/3q9GtMrnViRvNKxZNy2NEyb3TUWZS98qYqflrMmOusyAbE6+J7/QkIGcMi0VyqvxoAcO6U= X-Received: by 2002:a9d:58c5:: with SMTP id s5mr18826199oth.361.1556124431174; Wed, 24 Apr 2019 09:47:11 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 12:47:01 -0400 Message-ID: To: Ben Laurie Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000f255d80587497336" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 16:47:14 -0000 --000000000000f255d80587497336 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 4:53 AM Ben Laurie wrote: > If we are using QR codes to connect devices, we can transmit the necessary >> information without the user needing to notice that is what we are doing. >> Otherwise, there are many existing protocols that make comparison of 15-30 >> character base 32 encoded strings as the basis for mutual authentication >> and these have proved effective and acceptable. >> > > Oh really? Evidence? > We Chat has a billion accounts and is conservatively estimated to serve about 50% of the population of China. They use QR codes for contact exchange. https://en.wikipedia.org/wiki/WeChat One of the biggest problems that we have made for ourselves is making the perfect be the enemy of the good. We insisted on end-to-end secure email and got 0.1% of the mail user population enrolled for credentials of which less than 1% use end-to-end email regularly. If you want to offer security usability testing resources to improve on the schemes I am proposing, I would be more than happy to make any changes they suggest. But right now the situation is that it took me over 15 minutes to configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17 step process that requires use of a Web browser and email client and multiple switches between the two. It took me another ten minutes to find the instructions. When the current situation is that users are required to poke themselves in the eye with a sharp stick to get end-to-end security, it doesn't take very much to improve on that. --000000000000f255d80587497336 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2019 at 4:53 AM Ben Laurie <ben@links.org> wrote:
If we are using QR codes to connect devices, we can transmit the= necessary information without the user needing to notice that is what we a= re doing. Otherwise, there are many existing protocols that make comparison= of 15-30 character base 32 encoded strings as the basis for mutual authent= ication and these have proved effective and acceptable.

Oh really? Evidence?

We Chat has a billion accounts and is conservatively estimated to se= rve about 50% of the population of China. They use QR codes for contact exc= hange.

One of the biggest problems that we have made for our= selves is making the perfect be the enemy of the good. We insisted on end-t= o-end secure email and got 0.1% of the mail user population enrolled for cr= edentials of which less than 1% use end-to-end email regularly.

If you want to offer security usabil= ity testing resources to improve on the schemes I am proposing, I would be = more than happy to make any changes they suggest.

But right now the situation is that it took me ove= r 15 minutes to configure Thunderbird to use S/MIME. And I know what I am d= oing. It is a 17 step process that requires use of a Web browser and email = client and multiple switches between the two. It took me another ten minute= s to find the instructions.

When the current situation is that users are required to poke themselves= in the eye with a sharp stick to get end-to-end security, it doesn't t= ake very much to improve on that.

--000000000000f255d80587497336-- From nobody Wed Apr 24 09:52:41 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA76120321; Wed, 24 Apr 2019 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAoVZtWynhBu; Wed, 24 Apr 2019 09:52:37 -0700 (PDT) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 065BF12034D; Wed, 24 Apr 2019 09:52:34 -0700 (PDT) Received: by mail-qt1-f172.google.com with SMTP id b3so6198315qtc.12; Wed, 24 Apr 2019 09:52:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFpPR5uf0JdoufkYR8azFQdCri8mvMkH4yWRLJXALZA=; b=XdyO5oAq1WbX19BEnM9ksAXViR+BYbHaMOzkXBWpqd4kj70PyD17QxEra57sDRX7VS Xr/Ax12mS2dXI/C0d+2L5i9huReq4MLICEkWxLlCSd6iTWwbHMTXwZVsSDBrvlCdGCwb 2q5EtcgBI29u0LUpV6tMcSc612IpSX/Vb4T0OoaJV41TZAL2UW17oMV8Rl98qJR4MUV/ sVIPzZr2v4krpZ6guj0lnG9nCkLls+GAT82Yudk5CCPJc0gV+i8LgIeoYTcue+lD0fNn XuIvMwF08bfvNOyJ5OJwFWrDf6cjVg81YT2RM+6vAXpMHx+ZxTE30Cm/ZnwARvaGrMo2 OmRQ== X-Gm-Message-State: APjAAAXUeOwYEVWUGlNjCRtSJUiIuGMbs6NPkX7J/GfW1u7KPI6vk1pI Rel8RYUmx29pJPX70Tc6UuSozxdEHhnkLu25Fi0= X-Google-Smtp-Source: APXvYqzEUYSymcFVD1QmG5kjPPjR1qQqhZcfi1QfGXLfgbXmWYgXufUUJRIQrfIOMhkQpf/bp2LF9Yx1r7oug8ImNoA= X-Received: by 2002:a0c:fe4a:: with SMTP id u10mr5442559qvs.182.1556124752978; Wed, 24 Apr 2019 09:52:32 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Wed, 24 Apr 2019 17:52:22 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000020a8db058749870f" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 16:52:39 -0000 --00000000000020a8db058749870f Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker wrote: > On Wed, Apr 24, 2019 at 4:53 AM Ben Laurie wrote: > >> If we are using QR codes to connect devices, we can transmit the >>> necessary information without the user needing to notice that is what we >>> are doing. Otherwise, there are many existing protocols that make >>> comparison of 15-30 character base 32 encoded strings as the basis for >>> mutual authentication and these have proved effective and acceptable. >>> >> >> Oh really? Evidence? >> > > We Chat has a billion accounts and is conservatively estimated to serve > about 50% of the population of China. They use QR codes for contact > exchange. > > https://en.wikipedia.org/wiki/WeChat > "In China, digital marketing around QR code is an environmental feature of some international cities, such as Guangzhou, Shanghai and Beijing." Not so much around these parts. > One of the biggest problems that we have made for ourselves is making the > perfect be the enemy of the good. We insisted on end-to-end secure email > and got 0.1% of the mail user population enrolled for credentials of which > less than 1% use end-to-end email regularly. > This I do very much agree with. > > If you want to offer security usability testing resources to improve on > the schemes I am proposing, I would be more than happy to make any changes > they suggest. > > But right now the situation is that it took me over 15 minutes to > configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17 > step process that requires use of a Web browser and email client and > multiple switches between the two. It took me another ten minutes to find > the instructions. > > When the current situation is that users are required to poke themselves > in the eye with a sharp stick to get end-to-end security, it doesn't take > very much to improve on that. > I don't disagree with this, either. I do object, however, to assertions that things are obviously usable. --00000000000020a8db058749870f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 24 Apr 2019 at 17:47, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:
On We= d, Apr 24, 2019 at 4:53 AM Ben Laurie <ben@links.org> wrote:
If we are using QR codes to connect devices, we can transmit the ne= cessary information without the user needing to notice that is what we are = doing. Otherwise, there are many existing protocols that make comparison of= 15-30 character base 32 encoded strings as the basis for mutual authentica= tion and these have proved effective and acceptable.

Oh really? Evidence?

We Chat has a billio= n accounts and is conservatively estimated to serve about 50% of the popula= tion of China. They use QR codes for contact exchange.

=

"In China, digital marketing around = QR code is an environmental feature of some international cities, such as G= uangzhou, Shanghai and Beijing."

Not so much around these parts= .


One of the biggest problems that we have made for ours= elves is making the perfect be the enemy of the good. We insisted on end-to= -end secure email and got 0.1% of the mail user population enrolled for cre= dentials of which less than 1% use end-to-end email regularly.
<= /div>

This I do very much agree with.=
=C2=A0

If you want to offer security u= sability testing resources to improve on the schemes I am proposing, I woul= d be more than happy to make any changes they suggest.

But right now the = situation is that it took me over 15 minutes to configure Thunderbird to us= e S/MIME. And I know what I am doing. It is a 17 step process that requires= use of a Web browser and email client and multiple switches between the tw= o. It took me another ten minutes to find the instructions.

When the curr= ent situation is that users are required to poke themselves in the eye with= a sharp stick to get end-to-end security, it doesn't take very much to= improve on that.

I= don't disagree with this, either. I do object, however, to assertions = that things are obviously usable.

--00000000000020a8db058749870f-- From nobody Wed Apr 24 10:28:56 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DEB12010D; Wed, 24 Apr 2019 10:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 nLSgPkMVZtoR; Wed, 24 Apr 2019 10:28:48 -0700 (PDT) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (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 0FBB21200F6; Wed, 24 Apr 2019 10:28:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 219C52C28C9; Wed, 24 Apr 2019 17:28:47 +0000 (UTC) Received: from pdx1-sub0-mail-a82.g.dreamhost.com (100-96-11-130.trex.outbound.svc.cluster.local [100.96.11.130]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 52D4E2C20E6; Wed, 24 Apr 2019 17:28:46 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a82.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 24 Apr 2019 17:28:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Turn-Dime: 7e8c8d0b7edd552c_1556126926976_1125117772 X-MC-Loop-Signature: 1556126926975:2374531913 X-MC-Ingress-Time: 1556126926975 Received: from pdx1-sub0-mail-a82.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTP id A94887FE8E; Wed, 24 Apr 2019 10:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2CpHrdAShrvvvH to4JsvGM5PpMo=; b=g/6BeidDdH813gJapOKxMfseh8LT/En4Whd7ZXHgG0R3IK yVZK0dXYr5SVHeY31jCW23HpLL40DlGwwsTe822IYrZSYHN6Qqs9VcobKFSAJu1R RQuAVqP+tbYtHX0Bnwm+7gUpLBZQyEoq+uyzFoOyPq5Y94oaD5BYGujmbuXPE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTPSA id 45B437FE77; Wed, 24 Apr 2019 10:28:43 -0700 (PDT) Date: Wed, 24 Apr 2019 12:28:41 -0500 X-DH-BACKEND: pdx1-sub0-mail-a82 From: Nico Williams To: Ben Laurie Cc: Phillip Hallam-Baker , secdispatch@ietf.org, IETF SAAG Message-ID: <20190424172840.GJ3137@localhost> References: <20190422190302.GA3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrhedvgddtlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:28:50 -0000 On Wed, Apr 24, 2019 at 09:53:01AM +0100, Ben Laurie wrote: > On Tue, 23 Apr 2019 at 22:23, Phillip Hallam-Baker > wrote: > > On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie wrote: > >> On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker > >> wrote: > >> > >>> The primary focus is enabling real users to manage public key pairs on > >>> their devices without being aware that they are doing it. Securely > >>> establishing a set of public key pairs on each device and providing a > >>> validation path to the user's personal axiom of trust is the main idea > >>> here. Because if we achieve that, we are 80% of the way to securing almost > >>> any communication pattern. > >> > >> Where is the user testing for this? BTW, seems to me if users are not > >> aware that they are doing it, they will also not be aware when they are not > >> doing it. That doesn't seem like a path to security to me. Users absolutely have to be capable of being at least minimally aware. Perhaps we should leave UI issues till much later, provided we get consensus on a few "rules", with these as my proposal: 0) users absolutely have to be [capable of being] at least minimally aware of security 1) security UI indications should be minimally intrusive within constraint (0) I'm sure there are many UI design options, such as: - non-modal positive indicators - non-modal? negative indicators - reject negative interactions outright, with some sort of modal introducer option ("scan your peer's QR code" and such) - etc. Perhaps with different UI choices for different kinds of devices. Changes in device capabilities and form factors may well require re-thinking UI design choices. I don't care as much which if any or even all of the above are used, as long as we get (0) and (1). The degree of security indication UI intrusiveness is up for debate. We should give implementors guidance, but still let them experiment. > > Please make that point to the Chrome team who are busy stripping out the > > security indicators so users don't know if they are on a secure site or > > not. > > > > That is not what is happening. Chrome is switching from showing positive to > negative indicators. Thanks for this. Can you provide a link to justification/blogs/research about that change? Nico -- From nobody Wed Apr 24 10:49:07 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCE712009E; Wed, 24 Apr 2019 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XVfS3A34cFeX; Wed, 24 Apr 2019 10:49:05 -0700 (PDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (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 2EE9F120117; Wed, 24 Apr 2019 10:49:05 -0700 (PDT) Received: by mail-oi1-f193.google.com with SMTP id v7so15000247oie.8; Wed, 24 Apr 2019 10:49:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JLs7u6n0BLda+NKMeHxRGEXqjKQHeTSuL5qvBZULy5Y=; b=qKJB38gEvewNp2jk8Jxuv6DoZThNJpLir7P4vabtXiIt1EYnHsZe7JhM+9HNJQd3P0 gFetEmg8DIJi7xx0bkh+3/6R/jAxyn0Fp5sID+ayDDmJi0DigQp/w/bSWdtFVRD3EiCH gb4tJVH2j6iByKM1zycK6C6KmnXztngOxQ46Ll9u7hFBk/5/vdouZJJKqUW3B8/PWo59 V/thnXEKAAA2jPkW9myBOClto6Wmbk7ECb65OP83NPWp6DeE88fzXPh9w2kJCmhJDedL i3RcvHIVjnWfltXYUTPDairZ/73XelciquQjSbpD/g4CYE5nw2vcG5tooJ9Se1HDq3Kk QFgA== X-Gm-Message-State: APjAAAXhfJjfvQvzt47jR7enOQSARGQdTvhcuRdNleXNP1LiExpT5dFy bxM/4KiXm4uQdbGVbOfodBC0I6b/ji5ptRbmmX0= X-Google-Smtp-Source: APXvYqzte1uUtHyoA0sIWq6BkAkqbAvNSoWSqW4w+aFHDCQzkDEX3llRNWUNOoRJmh2a+IqOJHX05r56zFAZlmWkkpc= X-Received: by 2002:aca:c68b:: with SMTP id w133mr221595oif.58.1556128144012; Wed, 24 Apr 2019 10:49:04 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 13:48:53 -0400 Message-ID: To: Ben Laurie Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000003fbc1405874a514d" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:49:06 -0000 --0000000000003fbc1405874a514d Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 12:52 PM Ben Laurie wrote: > On Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker > wrote: > >> But right now the situation is that it took me over 15 minutes to >> configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17 >> step process that requires use of a Web browser and email client and >> multiple switches between the two. It took me another ten minutes to find >> the instructions. >> > >> When the current situation is that users are required to poke themselves >> in the eye with a sharp stick to get end-to-end security, it doesn't take >> very much to improve on that. >> > > I don't disagree with this, either. I do object, however, to assertions > that things are obviously usable. > My assertion was 'easier' not 'usable'. If a process has 17 steps and 16 are unnecessary, I don't need to do usability testing to know that it will be easier to use if we eliminate them. Well let me tell you what I am going to be doing on Sunday. I am going to be taking the scafolding out of where it is stored in the garage and building a tower in the master suite so that I can take down the #W$)(%$ Nest Protect device and update the WiFi settings to use a different WiFi access point after the old one was stolen. Someone obviously did a heck of a lot of user testing on the device but they never thought about the management and maintenance features that would be needed in the real world. I have connected my device to my WiFi network three separate times. Why does your product insist on tearing up my work and throwing it in my face? You control both the device and the app used to establish the connection. If you switched to using the Mesh approach, I would not need to repeat the process yet again. (And incidentally, the connection process does use QR codes and there is probably no need to change the user experience to enable use of a standards based approach) It is not just your company that has a problem with usability, Apple does as well. I have to go and help people configure the television because the Apple TV assumes that a person watching television can see well enough to read. Which might sound like a really good assumption until a 90 year old partially sighted deaf person wants to watch CNN. I would really like to be able to set out a control that has a limited number of buttons that directly provide the functions he needs but that would require a four or five figure investment in coding on my part. And the reason I brought up Apple and Nest is that they are produced by the companies that are the leaders in the usability field. But here is the thing, I don't think it was the usability testing that made the difference so much as the knowledge that the polo shirted one would have a screaming tantrum if someone had to climb a ladder to reconfigure a device whose very function requires that it be installed in the ceiling. The reason that the World Wide Web exists at all is that Tim Berners-Lee ignored the sage advice of the hypertext community that referential transparency was essential and pressed ahead with 'scruffy links'. Nobody did usability testing to decide whether the gopher or Web UI was the approach to follow until long after we knew the answer. My criticism of usability testing is this: we do not find out if buildings will stay up by building them and seeing if they fall down. That is exactly how it was done in the past which is why the Bent Pyramid collapsed during construction. Usability testing is the scientific approach. We should have moved past science and started practicing engineering. We should be able to predict with some confidence how users will react by applying principles learned from individual tests. Some classes of usability failure are quite easy to analyze. If a user faces two potential situations, case A and case B where one will lead to disaster and the other will perform the intended task and has no means of distinguishing these cases, the product is defective. Right now, I have no means of knowing if an email from my bank is actually an email from my bank or not. And that should be considered a problem. The problem I have with discussions of usability is that the argument is made that because we might not be able to serve every user we should just give up and never try to change anything. Like I said, if you want to propose changes to the protocol based on testing or even just based on advice from usability specialists, I am more than interested. But right now, the Mesh Reference Code is a command line tool and I am pretty sure that is not going to be the means of delivery that is most useful for end users. It is however the most useful means of delivery for people who want to build the Mesh into other applications and tools which is why we stopped developing the GUI tool and wrote the command line tool instead. --0000000000003fbc1405874a514d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2019 at 12:52 PM Ben Laurie <ben@links.org> wrote:
O= n Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker <phill@hallambaker.com> wrote:<= br>
But right now the situatio= n is that it took me over 15 minutes to configure Thunderbird to use S/MIME= . And I know what I am doing. It is a 17 step process that requires use of = a Web browser and email client and multiple switches between the two. It to= ok me another ten minutes to find the instructions.
<= div style=3D"font-size:small">
When= the current situation is that users are required to poke themselves in the= eye with a sharp stick to get end-to-end security, it doesn't take ver= y much to improve on that.

I don't disagree with this, either. I do object, however, to assertio= ns that things are obviously usable.
My asser= tion was 'easier' not 'usable'. If a process has 17 steps a= nd 16 are unnecessary, I don't need to do usability testing to know tha= t it will be easier to use if we eliminate them.


Well let me tell= you what I am going to be doing on Sunday. I am going to be taking the sca= folding out of where it is stored in the garage and building a tower in the= master suite so that I can take down the #W$)(%$ Nest Protect device and u= pdate the WiFi settings to use a different WiFi access point after the old = one was stolen.

Someone o= bviously did a heck of a lot of user testing on the device but they never t= hought about the management and maintenance features that would be needed i= n the real world.

I have = connected my device to my WiFi network three separate times. Why does your = product insist on tearing up my work and throwing it in my face? You contro= l both the device and the app used to establish the connection. If you swit= ched to using the Mesh approach, I would not need to repeat the process yet= again. (And incidentally, the connection process does use QR codes and the= re is probably no need to change the user experience to enable use of a sta= ndards based approach)

It= is not just your company that has a problem with usability, Apple does as = well. I have to go and help people configure the television because the App= le TV assumes that a person watching television can see well enough to read= . Which might sound like a really good assumption until a 90 year old parti= ally sighted deaf person wants to watch CNN. I would really like to be able= to set out a control that has a limited number of buttons that directly pr= ovide the functions he needs but that would require a four or five figure i= nvestment in coding on my part.

And the reason I brought up Apple and Nest is that they are produced= by the companies that are the leaders in the usability field.

But here is the thing, I don't th= ink it was the usability testing that made the difference so much as the kn= owledge that the polo shirted one would have a screaming tantrum if someone= had to climb a ladder to reconfigure a device whose very function requires= that it be installed in the ceiling.

The reason that the World Wide Web exists at all is that Tim B= erners-Lee ignored the sage advice of the hypertext community that referent= ial transparency was essential and pressed ahead with 'scruffy links= 9;. Nobody did usability testing to decide whether the gopher or Web UI was= the approach to follow until long after we knew the answer.


My criticism of usability testing is this: we do = not find out if buildings will stay up by building them and seeing if they = fall down. That is exactly how it was done in the past which is why the Ben= t Pyramid collapsed during construction.

Usability testing is the scientific approach. We should hav= e moved past science and started practicing engineering. We should be able = to predict with some confidence how users will react by applying principles= learned from individual tests.


Som= e classes of usability failure are quite easy to analyze. If a user faces t= wo potential situations, case A and case B where one will lead to disaster = and the other will perform the intended task and has no means of distinguis= hing these cases, the product is defective.

Right now, I have no means of knowing if an email from= my bank is actually an email from my bank or not. And that should be consi= dered a problem. The problem I have with discussions of usability is that t= he argument is made that because we might not be able to serve every user w= e should just give up and never try to change anything.

Like I said, if you want to propose changes = to the protocol based on testing or even just based on advice from usabilit= y specialists, I am more than interested. But right now, the Mesh Reference= Code is a command line tool and I am pretty sure that is not going to be t= he means of delivery that is most useful for end users.

It is however the most useful means of deliv= ery for people who want to build the Mesh into other applications and tools= which is why we stopped developing the GUI tool and wrote the command line= tool instead.
--0000000000003fbc1405874a514d-- From nobody Wed Apr 24 10:51:13 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F9012009E for ; Wed, 24 Apr 2019 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 rQAJ0UA9PITc for ; Wed, 24 Apr 2019 10:51:01 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 2900912011E for ; Wed, 24 Apr 2019 10:51:01 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id y131so4658885ywa.9 for ; Wed, 24 Apr 2019 10:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bUEuTUeeGg7YmNlU9oCfjaYP5PEjUjo7tdYJfMerZ1A=; b=vWxsHjjbHI2hVruJW1cZMb0LRgAv62tue+R+o6Wl40uRlB4wg5pifnxYJsYGp6Mhkx +tKRpua7hK/dGaF1K4ek+WREhGLXceWL1hDzpDHASeZwAaqC0zV987bdTKi0qAcmXBer xeRV2LJA5TLZsE2JegGYQawuvVXLH9ID+eD/z5Y0tqDQfZcoziBl2j9eetvOzM4HENdI WgvQn+R9gEJlBTK9O88IIraRaFIsVPfe0TVNy6+ndHNJ7Eg4kOorHihHRMm+0EptMIj/ i6r+/nKYQKUQpRvkAHMCKFRFgY+5E/5Rb+ZKU2t4WDsUR3ebWnnBxiFZqMZKphzoOafc O8xw== 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=bUEuTUeeGg7YmNlU9oCfjaYP5PEjUjo7tdYJfMerZ1A=; b=ffsDXWcqYvct97vpmGsmgZZNX5OLqygKj1zNNBmD7LTsMH/Slm4tv3B8IWBTqEwI3t Kgcbvc8GSU+9mR1n5C8w+C4mhNAIrhpaf9hGI6+oEi8F1eAtQiWI5OePjRCk6VwZjJU3 Fq9geM6vLF8qXO3S3U9Bn4aPcXmZa/FyzZOKySyHS95wQLT4tpIfh4IroF6XLt7nb5fF QbH8GD3w4IcFj0LYWjCM74WwzwI9KRl65QX+WgI7DumBHROLJAgf1xDaZRQtXSHqFBZl e7a2hJupIumqlN38tlV7fxHngoYUh/aDO297VcsGubY6tGtjXDjBhy28t1yAey71Xhsm x/2A== X-Gm-Message-State: APjAAAXSXY5J5SCoBb97nfwD2B4vA/yP0FMDUZYjRHPTAXBsMcb6sjz/ TIecVohttpAMnZagTFvwTR6C9jVMOBqJbjp6i3L7tA== X-Google-Smtp-Source: APXvYqxDFRXQL27RqOzAlbwG1kUfwpd9GuwL0AMH0cr3oGZkJWx6/QlVCrFsvHxpWxOG/+5m2I/e4gbxogWqGOo3sdM= X-Received: by 2002:a81:55c1:: with SMTP id j184mr16914355ywb.311.1556128260146; Wed, 24 Apr 2019 10:51:00 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> <20190424172840.GJ3137@localhost> In-Reply-To: <20190424172840.GJ3137@localhost> From: Ben Laurie Date: Wed, 24 Apr 2019 18:50:45 +0100 Message-ID: To: Nico Williams Cc: Ben Laurie , IETF SAAG , secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000002c3c0505874a588a" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:51:04 -0000 --0000000000002c3c0505874a588a Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 18:29, Nico Williams wrote: > On Wed, Apr 24, 2019 at 09:53:01AM +0100, Ben Laurie wrote: > > Chrome is switching from showing positive to > > negative indicators. > > Thanks for this. Can you provide a link to justification/blogs/research > about that change? > https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html is a good starting point. Adrienne Porter Felt's research is also worth looking into. --0000000000002c3c0505874a588a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000002c3c0505874a588a-- From nobody Wed Apr 24 11:01:55 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4E4120118 for ; Wed, 24 Apr 2019 11:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 jhcHbDaOLVHw for ; Wed, 24 Apr 2019 11:01:43 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 879B812011E for ; Wed, 24 Apr 2019 11:01:43 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id e190so7462325ybf.2 for ; Wed, 24 Apr 2019 11:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=phI0EIwQpAAsAqI+wyYi90h9Pb/udQGPegsf0KeZrQ0=; b=QS6RvMx+EIreyX9Hzs5Ak/K4NTlMtLJrHN2HP61yo5hHIPOs8aE7PlAHJMF+q75YQp DtzM/fnNF9kwlX2UdldFZ1KG9bQ6bFya0tJe1nuVXbAtG2YsT9+QMc+fKud6PB1vLGr1 +EwjEJnjE90f35qWggMGFfpmchBgN/vcu9CrU8BW3fYvgpa6dERiu7AWQxMPpSkIulFq KPZ647tncDKKLptPRmGesAt7iSJSOES855TbQ1SNPH3UDBdd8O3cElb+cl7z0SQXIZ7W +Xu8hsf0awtWjDRz1xOZuG9HTHHyLcs1Tl45/w2EJ9+V0oKeZmiAE5y9jIhDNXNgC6ik 0Tfg== 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=phI0EIwQpAAsAqI+wyYi90h9Pb/udQGPegsf0KeZrQ0=; b=rA+tleckNRGz2SeyW0gH4/0Kmu2wF3mL7sjza2lzpQGuaCYfM8mlTSvRK2V771UkxF Nfcy9Cye6hOc3Q6f7z3G+1bFyW8CfvTCASwJFQgf1OWfP1bNdgHLtK0Dp9yqaWTD5Q6o kva9Mqrqyr+qKc+YIvjZ8LrWXxhQeFgN0fQ55QTXDHInMABlw7reONMRgG6jnWiiRE28 JByTCGXwh8rNA0OvMtHTgAIs3b3uHtV4SivHtlrVfu3QgA+DHoj5E/OYm7QqIxNG0P2x XWLQAn9SctLtGjzBfOy3U6Hyvi/v2/3HCKQS8L00lVdGIrCjaLntYoEPUMO2FtE9FeHM rciw== X-Gm-Message-State: APjAAAW5vITQBc0Woyy1bimqtwb6aBREX4xLdTNVF9bV/s3mgzBVFy4u amOEUPyiIVU8AKiYh9M51uM5NLx9vDxUhweBKUY+Yow+R1k= X-Google-Smtp-Source: APXvYqyoeJtO8TQvWStR5jsDWHQDbpEk0adahyKDBUstkk5Cr61TURUzhHQhvZ+CYcs2tm41eyPNNmASHwLq6PhFY68= X-Received: by 2002:a25:b317:: with SMTP id l23mr3125809ybj.513.1556128902404; Wed, 24 Apr 2019 11:01:42 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Ben Laurie Date: Wed, 24 Apr 2019 19:01:28 +0100 Message-ID: To: Phillip Hallam-Baker Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000074533805874a7ea5" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 18:01:47 -0000 --00000000000074533805874a7ea5 Content-Type: text/plain; charset="UTF-8" On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker wrote: > > The reason that the World Wide Web exists at all is that Tim Berners-Lee > ignored the sage advice of the hypertext community that referential > transparency was essential and pressed ahead with 'scruffy links'. Nobody > did usability testing to decide whether the gopher or Web UI was the > approach to follow until long after we knew the answer. > This is a clear case of survivorship bias. The users did the usability testing. WWW survived (despite being technically terrible in many ways), the competitors did not. > My criticism of usability testing is this: we do not find out if buildings > will stay up by building them and seeing if they fall down. That is exactly > how it was done in the past which is why the Bent Pyramid collapsed during > construction. > > Usability testing is the scientific approach. We should have moved past > science and started practicing engineering. We should be able to predict > with some confidence how users will react by applying principles learned > from individual tests. > Indeed, somewhat possible. Some classes of usability failure are quite easy to analyze. If a user > faces two potential situations, case A and case B where one will lead to > disaster and the other will perform the intended task and has no means of > distinguishing these cases, the product is defective. > > Right now, I have no means of knowing if an email from my bank is actually > an email from my bank or not. And that should be considered a problem. The > problem I have with discussions of usability is that the argument is made > that because we might not be able to serve every user we should just give > up and never try to change anything. > Well, the problem I have with discussions of usability is the argument is made that we should leave that until all the tech is figured out, or that we don't need to bother because the thing is obviously better. Going from .1% to 1% is clearly an improvement, but it is not a solution. BTW, my original question was not about QR codes (though I have my doubts about those), but about this assertion about usability: "Otherwise, there are many existing protocols that make comparison of 15-30 character base 32 encoded strings as the basis for mutual authentication and these have proved effective and acceptable." -- I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w. #VerifyAllTheThings. *https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22 * --00000000000074533805874a7ea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 24 Apr 2019 at 18:49, Phillip= Hallam-Baker <phill@hallambake= r.com> wrote:

<= /div>
The re= ason that the World Wide Web exists at all is that Tim Berners-Lee ignored = the sage advice of the hypertext community that referential transparency wa= s essential and pressed ahead with 'scruffy links'. Nobody did usab= ility testing to decide whether the gopher or Web UI was the approach to fo= llow until long after we knew the answer.

This is a clear case of survivorship bias. The users did t= he usability testing. WWW survived (despite being technically terrible in m= any ways), the competitors did not.

=C2=A0
My criticism of usability t= esting is this: we do not find out if buildings will stay up by building th= em and seeing if they fall down. That is exactly how it was done in the pas= t which is why the Bent Pyramid collapsed during construction.

Usability = testing is the scientific approach. We should have moved past science and s= tarted practicing engineering. We should be able to predict with some confi= dence how users will react by applying principles learned from individual t= ests.

Indeed, somewhat po= ssible.

Some classes of usability failure are quite easy to analyze. If a user f= aces two potential situations, case A and case B where one will lead to dis= aster and the other will perform the intended task and has no means of dist= inguishing these cases, the product is defective.

Right now, I have no me= ans of knowing if an email from my bank is actually an email from my bank o= r not. And that should be considered a problem. The problem I have with dis= cussions of usability is that the argument is made that because we might no= t be able to serve every user we should just give up and never try to chang= e anything.

Well, the pro= blem I have with discussions of usability is the argument is made that we s= hould leave that until all the tech is figured out, or that we don't ne= ed to bother because the thing is obviously better. Going from .1% to 1% is= clearly an improvement, but it is not a solution.

BTW, my original question was not about QR codes (though I have my doubts = about those), but about this assertion about usability: "Otherwise, th= ere are many existing protocols that make comparison of 15-30 character bas= e 32 encoded strings as the basis for mutual authentication and these have = proved effective and acceptable."


<= /div>--
I am hiring! Formal methods, UX, management, SWE ... ver= ified s/w and h/w. #VerifyAllTheThings.

--00000000000074533805874a7ea5-- From nobody Wed Apr 24 14:15:56 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB26E120290; Wed, 24 Apr 2019 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nvUxaYvHgB3; Wed, 24 Apr 2019 14:15:52 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (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 3DB7A12014E; Wed, 24 Apr 2019 14:15:52 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id v10so15527242oib.1; Wed, 24 Apr 2019 14:15:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aH23A9foeZfCYyknRPZWdPQU/jqp+lqDwufuX+TPgjU=; b=HmdVIIeW7ucJOrCc6Mr5rWsOD4ekXk5Dvlxyc8H08J2p8N+qbcB/HuK6nOl5mYjq0V 6t40O3n5qyhu5kJ8xH5TsmygDc07KTHNauXGSeza+b1rQdkwFp5n6Uy1+GA2afNSnkDZ uBqH/NsNi/HhfV/ejrjiqb6TNXdERWTLXId84Ogb1BOYH+HiRgA27sjIvaSS9Gnl2ntY IYtEQXJwol60sZp0Np7XTgtxB+PQeY+8OlUCJuEKlWN0LcywMrJ+jt9B7OYrLqZj9mQg TMOBe+8PimrrsCWGlaxnwymvYesIiNGjzGPYoUUdxofbYlUQhkyTLCdjzme27ZOu4EA0 58HQ== X-Gm-Message-State: APjAAAUPGL61/bpV49J3gGMrZiPVkl+raeL2T6jJcV6RWKAh1rkWDi5k KdsFYmPJ3fOU7Wy5VmgBqeJkWVxeD9qBEv0wp80= X-Google-Smtp-Source: APXvYqyjnBzS2yQSRMcU8bWhwV2QLt3shR+5HaTLbjy0BMDybj+GMwA/+ad3oDBEwRcRTYadxcKtMpTf9fK9f3jxAnE= X-Received: by 2002:aca:43d5:: with SMTP id q204mr838602oia.100.1556140551442; Wed, 24 Apr 2019 14:15:51 -0700 (PDT) MIME-Version: 1.0 References: <20190422190302.GA3137@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 24 Apr 2019 17:15:41 -0400 Message-ID: To: Ben Laurie Cc: Ben Laurie , secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ca1a1b05874d349e" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 21:15:54 -0000 --000000000000ca1a1b05874d349e Content-Type: text/plain; charset="UTF-8" On Wed, Apr 24, 2019 at 2:01 PM Ben Laurie wrote: > > > On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker > wrote: > >> >> The reason that the World Wide Web exists at all is that Tim Berners-Lee >> ignored the sage advice of the hypertext community that referential >> transparency was essential and pressed ahead with 'scruffy links'. Nobody >> did usability testing to decide whether the gopher or Web UI was the >> approach to follow until long after we knew the answer. >> > > This is a clear case of survivorship bias. The users did the usability > testing. WWW survived (despite being technically terrible in many ways), > the competitors did not. > The Web had 100 users in the fall of 1992 when it was first demonstrated in public. There were at least two dozen competing network hypertext systems, most of which were far better financed than the Web which had two full time staff at the time. Nine months later the Web had over a million users and it was game over for every other network hypertext scheme apart from Acrobat which had already begun merging itself with the Web to survive. There was rather more than survivor bias at work there. One of the biggest differences between the Web and everything else was that Eric Binna paid immense attention to the quality of his software distributions. He provided binary distributions for a start and the code compiled from source. We paid a great deal of attention to usability but we never had the resources to test any of it. There was never a testing lab at CERN for a start. Or at NCSA as far as I am aware. Come to think of it, when VeriSign acquired the old Netscape HQ, I pushed for the construction of a usability lab. Which means that there wasn't one in the building when we moved in. Right now, I have no means of knowing if an email from my bank is actually >> an email from my bank or not. And that should be considered a problem. The >> problem I have with discussions of usability is that the argument is made >> that because we might not be able to serve every user we should just give >> up and never try to change anything. >> > > Well, the problem I have with discussions of usability is the argument is > made that we should leave that until all the tech is figured out, or that > we don't need to bother because the thing is obviously better. Going from > .1% to 1% is clearly an improvement, but it is not a solution. > Like I said, I am more than happy to accept input on how to do UI better. But I am not going to be blocked on those resources. At this point I have one employee and a seven figure budget. To start thinking about UI testing I need to have more developers and a bigger budget. > BTW, my original question was not about QR codes (though I have my doubts > about those), but about this assertion about usability: "Otherwise, there > are many existing protocols that make comparison of 15-30 character base 32 > encoded strings as the basis for mutual authentication and these have > proved effective and acceptable." > I have entered product activation keys and lived. Adobe managed to sell software with that requirements for decades. So they are not a show stopper for at least some part of the audience. I am requiring only comparison of two codes, not entry. I accept that this is not the ideal approach and in the spec I suggest using BASE32K encoding based on dictionaries of words or images. Since the connection mechanism only requires comparison for equality, we don't have to be restricted to something that can be entered on a keyboard. Images would be the ideal of course because they can be language independent. 'Are these nine pictures the same' is a pretty easy question to answer. The work factor for the UDF approach would be (9*15)-8 = 127. 2^127 is sufficient for most purposes. Comparing nine pictures for equality is relatively straightforward. I haven't gone into this in detail as yet, but my rough strategy for managing the dictionaries is to 1) Sort the entries into a canonical sort order 2) Form a Merkle tree of the result. 3) Publish the apex of the tree in some tamper-proof fashion. This avoids the need to store the entire dictionary on every device which is important even for unconstrained devices. The image dictionary is going to be huge and word dictionaries have to be customized to the user's language. It has not escaped my notice that I could use this as a funding mechanism for the Mesh itself. The million dollar image dictionary. Companies could pay to contribute images to the corpus, part of which could be reserved for advertising. If the system was used a million times a day, $1 would buy nine exposures of the image per day in perpetuity. Or until someone decided to do an advert-free version. --000000000000ca1a1b05874d349e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 24, 2019 at 2:01 PM Ben Laurie <benl@google.com> wrote:


On Wed, 24 Apr 2019 at 18:49, Phillip Hallam-Baker <phill@hallambaker.com&g= t; wrote:

=
The reason that t= he World Wide Web exists at all is that Tim Berners-Lee ignored the sage ad= vice of the hypertext community that referential transparency was essential= and pressed ahead with 'scruffy links'. Nobody did usability testi= ng to decide whether the gopher or Web UI was the approach to follow until = long after we knew the answer.

This is a clear case of survivorship bias. The users did the usabilit= y testing. WWW survived (despite being technically terrible in many ways), = the competitors did not.

=
The Web had 100 user= s in the fall of 1992 when it was first demonstrated in public. There were = at least two dozen competing network hypertext systems, most of which were = far better financed than the Web which had two full time staff at the time.=

Nine months later the We= b had over a million users and it was game over for every other network hyp= ertext scheme apart from Acrobat which had already begun merging itself wit= h the Web to survive.

The= re was rather more than survivor bias at work there. One of the biggest dif= ferences between the Web and everything else was that Eric Binna paid immen= se attention to the quality of his software distributions. He provided bina= ry distributions for a start and the code compiled from source.

We paid a g= reat deal of attention to usability but we never had the resources to test = any of it. There was never a testing lab at CERN for a start. Or at NCSA as= far as I am aware. Come to think of it, when VeriSign acquired the old Net= scape HQ, I pushed for the construction of a usability lab. Which means tha= t there wasn't one in the building when we moved in.

Right no= w, I have no means of knowing if an email from my bank is actually an email= from my bank or not. And that should be considered a problem. The problem = I have with discussions of usability is that the argument is made that beca= use we might not be able to serve every user we should just give up and nev= er try to change anything.

Well, the problem I have with discussions of usability is the argumen= t is made that we should leave that until all the tech is figured out, or t= hat we don't need to bother because the thing is obviously better. Goin= g from .1% to 1% is clearly an improvement, but it is not a solution.
=

Like I said, I am more than happy to accept input = on how to do UI better. But I am not going to be blocked on those resources= . At this point I have one employee and a seven figure budget. To start thi= nking about UI testing I need to have more developers and a bigger budget.<= /div>
=C2=A0
BTW, my original qu= estion was not about QR codes (though I have my doubts about those), but ab= out this assertion about usability: "Otherwise, there are many existin= g protocols that make comparison of 15-30 character base 32 encoded strings= as the basis for mutual authentication and these have proved effective and= acceptable."

I have entered product act= ivation keys and lived. Adobe managed to sell software with that requiremen= ts for decades. So they are not a show stopper for at least some part of th= e audience. I am requiring only comparison of two codes, not entry.

I accept that this is not the = ideal approach and in the spec I suggest using BASE32K encoding based on di= ctionaries of words or images. Since the connection mechanism only requires= comparison for equality, we don't have to be restricted to something t= hat can be entered on a keyboard. Images would be the ideal of course becau= se they can be language independent. 'Are these nine pictures the same&= #39; is a pretty easy question to answer. The work factor for the UDF appro= ach would be (9*15)-8 =3D 127. 2^127 is sufficient for most purposes. Compa= ring nine pictures for equality is relatively straightforward.

I haven't gone into this in detai= l as yet, but my rough strategy for managing the dictionaries is to

1) Sort the entries into a can= onical sort order
2) Form a Merkle tree of the result.
3) Publish the apex of the tree in some tamper-pro= of fashion.
This avoids t= he need to store the entire dictionary on every device which is important e= ven for unconstrained devices. The image dictionary is going to be huge and= word dictionaries have to be customized to the user's language.
<= div class=3D"gmail_default" style=3D"font-size:small">

It has not escaped my notice that I coul= d use this as a funding mechanism for the Mesh itself. The million dollar i= mage dictionary. Companies could pay to contribute images to the corpus, pa= rt of which could be reserved for advertising. If the system was used a mil= lion times a day, $1 would buy nine exposures of the image per day in perpe= tuity. Or until someone decided to do an advert-free version.

=C2=A0
--000000000000ca1a1b05874d349e-- From nobody Thu Apr 25 09:14:34 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F008F120225; Thu, 25 Apr 2019 09:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 KRvFeakVwf2R; Thu, 25 Apr 2019 09:14:15 -0700 (PDT) Received: from firebrick.maple.relay.mailchannels.net (firebrick.maple.relay.mailchannels.net [23.83.214.59]) (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 AF6031202FD; Thu, 25 Apr 2019 09:14:13 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 74FD22C2070; Thu, 25 Apr 2019 16:14:12 +0000 (UTC) Received: from pdx1-sub0-mail-a23.g.dreamhost.com (100-96-2-149.trex.outbound.svc.cluster.local [100.96.2.149]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EA9562C2168; Thu, 25 Apr 2019 16:14:10 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a23.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 25 Apr 2019 16:14:12 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Sponge-Cellar: 1871ab8c00823e71_1556208851885_4196924436 X-MC-Loop-Signature: 1556208851885:185892603 X-MC-Ingress-Time: 1556208851884 Received: from pdx1-sub0-mail-a23.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a23.g.dreamhost.com (Postfix) with ESMTP id 6036781CE4; Thu, 25 Apr 2019 09:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LhlUWfYOOkKiV5 rgwe05HSL89K8=; b=eBIPYlTT6DnsEwnIXB06FkHcFNm+BH4rQBfoucaUQUc0V9 68x5DefJnGR83aEsCvHgfN6OAltR0oHZWgv55n3DMlTvfXLkGhVHcjUfUpKxT/th L6MpxzWZT3Ujed18B2+JzV3RtmxGDOaNdAZQWc+ogax0oQ+5793KembWz5Vy4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 1B61F81CE0; Thu, 25 Apr 2019 09:14:07 -0700 (PDT) Date: Thu, 25 Apr 2019 11:14:05 -0500 X-DH-BACKEND: pdx1-sub0-mail-a23 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, saag@ietf.org Message-ID: <20190425161404.GS3137@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrheeggdelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 16:14:27 -0000 Now that I understand what the proposal is, I have to say that I like it. There are some important new things in it, mostly the use of a blockchain for PGP-style web-of-trust, and an Internet protocol for device key management (which is separable but doesn't need to be separated). The first is a new application of existing ideas, but it is critical to facilitating the use of web-of-trust. The most important thing about the proposal is that it's a synthesis of the above and an all-of-the-above approach to communication security for average users, and that it's a proposal for Standards-Track Internet protocols. As such it has better chance of success than the disparate piecemeal efforts of the industry as a whole until now. Count on me as a reviewer, Nico -- From nobody Thu Apr 25 14:12:16 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5312004C; Thu, 25 Apr 2019 14:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 wd-TNiiIo_GE; Thu, 25 Apr 2019 14:12:13 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283FE120044; Thu, 25 Apr 2019 14:12:13 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id e5so784985otk.12; Thu, 25 Apr 2019 14:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VHX+0lPDmVg+sXjWF/BgwByYc3WQw+RO3k6xAS5I99c=; b=B/lP7a7ppVZO7nfLsnuobQvEme5xSvXQuEC1H+Yyb3+SicACOML0ACB45ZuwAEZfN8 AZGVA2kWT0LNJ6HroUMu8g2OkV66PavEKgYCmBBSrBlt3d+CpUMj5EWVvgfohXRfS/08 PxA5lDfBFYTf97Qilmrq4cstNcf1qLHiz4HUtydeB7MnU6b/yb11wrftxHVxgdnIkI0W 4vf1uNopUCJiavlHDYNGmaurpMt0m6g9G1LCndKEJSLNmRZPljpLkX4VrclfSKjJTI0C Cut7QdmvE8eSHgXFCP/1G/aSeh1KNfxtBCZflcb3bBn1QQ46c1FXcfHUdE+aY6b4Um4Z PBXA== X-Gm-Message-State: APjAAAWCj2zvqMkdI6j/f6IKUf5AwKIlFc+S3FlgjpNGNFZobC6Q+TSo mqulbHuIsRG6gViuFHxZ8lEcdRGwDuqFDOAO3f8= X-Google-Smtp-Source: APXvYqxxoZmOUQYNwBeLaSt9onH3N1Q75Ois4SwMzob+G5NtKV9EjUMDnnU5fxH0W7rsa50UkGQNi2FeXG/3eHhxrkg= X-Received: by 2002:a05:6830:1017:: with SMTP id a23mr26225817otp.120.1556226732382; Thu, 25 Apr 2019 14:12:12 -0700 (PDT) MIME-Version: 1.0 References: <20190425161404.GS3137@localhost> In-Reply-To: <20190425161404.GS3137@localhost> From: Phillip Hallam-Baker Date: Thu, 25 Apr 2019 17:12:00 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="00000000000092de5e058761454c" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:12:15 -0000 --00000000000092de5e058761454c Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 12:14 PM Nico Williams wrote: > > Now that I understand what the proposal is, I have to say that I like > it. > > There are some important new things in it, mostly the use of a > blockchain for PGP-style web-of-trust, and an Internet protocol for > device key management (which is separable but doesn't need to be > separated). The first is a new application of existing ideas, but it > is critical to facilitating the use of web-of-trust. > Just to be clear: It is a similar approach to blockchain. The encoding used is entirely separate. The DARE Container allows append only logs to be created with individual entries of up to 2^63 bytes in length. So we could use the same format as a file archiving format or even a software distribution format. The encoding allows the container sequence to be read with equal efficiency in the forward or the reverse direction and while every entry can have a separate key exchange and signature, the entire container can be authenticated and encrypted at the entry level using a single key exchange in the first entry and a single signature entry on the last entry. So we could use this as a ZIP file for distributing Web pages. But unlike ZIP, the signatures are based on a Merkle tree so we can validate individual entries. So we could use this as a software distribution format. Put all the files for all the distributions on all platforms into one big file. Then the distribution system can extract the specific set of files needed for specific platforms weeding out the ones that aren't needed. The same approach can be used for software updates. since the containers are append only. All you need to do to push out updates is to synchronize the containers across devices. The reason I was able to simplify the Mesh code was that I realized that all my application protocols could be implemented as instances of synchronizing containers between devices. > The most important thing about the proposal is that it's a synthesis of > the above and an all-of-the-above approach to communication security for > average users, and that it's a proposal for Standards-Track Internet > protocols. As such it has better chance of success than the disparate > piecemeal efforts of the industry as a whole until now. > > Count on me as a reviewer, Thanks, that is greatly appreciated. The status of the current drafts is that the text is more or less complete, there are some missing images and multiple missing examples. The reason for that is that I alternate between writing the documentation and implementing it. I began by writing the documentation, wrote the code, went back and wrote new documentation describing the code and so on. The last set of changes was motivated my my leaving Comodo. Originally, the DARE work was an application that built on the Mesh capabilities. I rewrote the code so that the Mesh is now built on top of DARE. That allowed me to eliminate two thirds of it. --00000000000092de5e058761454c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2019 at 12:14 PM Nico Williams <nico@cryptonector.com> wrote:

Now that I understand what the proposal is, I have to say that I like
it.

There are some important new things in it, mostly the use of a
blockchain for PGP-style web-of-trust, and an Internet protocol for
device key management (which is separable but doesn't need to be
separated).=C2=A0 The first is a new application of existing ideas, but it<= br> is critical to facilitating the use of web-of-trust.
<= br>
Just t= o be clear: It is a similar approach to blockchain. The encoding used is en= tirely separate.=C2=A0

The DARE Container allows append only logs to be cre= ated with individual entries of up to 2^63 bytes in length. So we could use= the same format as a file archiving format or even a software distribution= format.

The encoding all= ows the container sequence to be read with equal efficiency in the forward = or the reverse direction and while every entry can have a separate key exch= ange and signature, the entire container can be authenticated and encrypted= at the entry level using a single key exchange in the first entry and a si= ngle signature entry on the last entry.=C2=A0

So we could use this as a ZIP file for distributing We= b pages. But unlike ZIP, the signatures are based on a Merkle tree so we ca= n validate individual entries.

So we could use this as a software distribution format. Put all the f= iles for all the distributions on all platforms into one big file. Then the= distribution system can extract the specific set of files needed for speci= fic platforms weeding out the ones that aren't needed.=C2=A0

The same approach can be used for s= oftware updates. since the containers are append only. All you need to do t= o push out updates is to synchronize the containers across devices.


The reason I was able to simplify the Me= sh code was that I realized that all my application protocols could be impl= emented as instances of synchronizing containers between devices.

=

=C2=A0
The most important thing about the proposal is that it's a synthesis of=
the above and an all-of-the-above approach to communication security for average users, and that it's a proposal for Standards-Track Internet protocols.=C2=A0 As such it has better chance of success than the disparate=
piecemeal efforts of the industry as a whole until now.

Count on me as a reviewer,
=C2=A0
Thanks, that is greatly appreciated. Th= e status of the current drafts is that the text is more or less complete, t= here are some missing images and multiple missing examples.

The reason for that is that I alternate = between writing the documentation and implementing it. I began by writing t= he documentation, wrote the code, went back and wrote new documentation des= cribing the code and so on.

The last set of changes was motivated my my leaving Comodo. Originally, = the DARE work was an application that built on the Mesh capabilities. I rew= rote the code so that the Mesh is now built on top of DARE. That allowed me= to eliminate two thirds of it.
--00000000000092de5e058761454c-- From nobody Thu Apr 25 14:42:45 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C701120260; Thu, 25 Apr 2019 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 uehRfrH6QkE2; Thu, 25 Apr 2019 14:42:40 -0700 (PDT) Received: from ostrich.birch.relay.mailchannels.net (ostrich.birch.relay.mailchannels.net [23.83.209.138]) (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 6717612025C; Thu, 25 Apr 2019 14:42:40 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E2D6C5C5B28; Thu, 25 Apr 2019 21:42:38 +0000 (UTC) Received: from pdx1-sub0-mail-a22.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 952935C5AD2; Thu, 25 Apr 2019 21:42:38 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a22.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 25 Apr 2019 21:42:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arithmetic-Stop: 4dfcbe24222139ea_1556228558719_4189485943 X-MC-Loop-Signature: 1556228558718:3285635047 X-MC-Ingress-Time: 1556228558718 Received: from pdx1-sub0-mail-a22.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTP id 54E80825D6; Thu, 25 Apr 2019 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=V4YaBM4/+cFl7+ uSG86P/Zz2RP0=; b=c30Gq3dra2TBG+tA2aR9jXTo2PIzDt9YFI25XwVe6SoSkE fdvFjK30BnjAe6N6/S1j878clOpLnInrgQvri+mvBtSiI+cHEJDMvl3qUZRcy7zC mvVK+FAwrSH5Unl766EbKBqi9XAyB5yl/NZWjBccb6jyvUMsiU4VVW9YZKQBk= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTPSA id DD610825D8; Thu, 25 Apr 2019 14:42:36 -0700 (PDT) Date: Thu, 25 Apr 2019 16:42:34 -0500 X-DH-BACKEND: pdx1-sub0-mail-a22 From: Nico Williams To: Phillip Hallam-Baker Cc: secdispatch@ietf.org, IETF SAAG Message-ID: <20190425214233.GX3137@localhost> References: <20190425161404.GS3137@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrheehgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:42:43 -0000 On Thu, Apr 25, 2019 at 05:12:00PM -0400, Phillip Hallam-Baker wrote: > On Thu, Apr 25, 2019 at 12:14 PM Nico Williams > wrote: > > Just to be clear: It is a similar approach to blockchain. The encoding used > is entirely separate. Understood. The point is that you end up with a cryptographic append-only log. > The reason I was able to simplify the Mesh code was that I realized that > all my application protocols could be implemented as instances of > synchronizing containers between devices. Nice. > > Count on me as a reviewer, > > Thanks, that is greatly appreciated. The status of the current drafts is > that the text is more or less complete, there are some missing images and > multiple missing examples. Is that a request for review sooner than later? > The reason for that is that I alternate between writing the documentation > and implementing it. I began by writing the documentation, wrote the code, > went back and wrote new documentation describing the code and so on. Understood. Nico -- From nobody Thu Apr 25 15:14:52 2019 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B3E120343; Thu, 25 Apr 2019 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 FMU2Fau5Y55J; Thu, 25 Apr 2019 15:14:49 -0700 (PDT) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF4D1200F8; Thu, 25 Apr 2019 15:14:49 -0700 (PDT) Received: by mail-ot1-f45.google.com with SMTP id u17so982108otj.1; Thu, 25 Apr 2019 15:14:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SbupJ67oYGL4CrkcEAz7h1s2KKC5mw30lm7T6hYyzzo=; b=YvNpCxlVN2eM4/ciiZtAcEZWuJ+1yJE7aGz/HvAgvKAYF51j2HslOPyMOMOGuFHImr TgQT4t1vDDurnkY/7lRJFKWNqLQNADJg6vmiK2JQtRHuPCtYDifZRejyguDeZuwCdiLt OwZqDTWFjlEQVMn2mJqSGW6AlV9U3nW94naqRwfL0iK5E6WUJNxYW8sz10rFBuY2O5BT VUQ1wXV1dOCiUbA1yDBQ77Xd9IqZLBewiDmShwB8OjW385z0FQvyD0NveppGm3xLeWti XK7DW/nYqfL6E4tLRVRvAGlbTAJF1ChJLqozVwYRrQoDjyVFns3Aq3lf5K+/X+e6Amn7 9TJg== X-Gm-Message-State: APjAAAUpMaYywbAus2M2TrQP2hqHXhkkuHCUmyMHJPVr215n16zG73BQ G1sU9+AlsBc95uUeHslYDlhJ0bjLVtlMrOR/fq0= X-Google-Smtp-Source: APXvYqzC0hkyYXkFo48KFe/UTSDz7iSpvc47eyzoYaxZdRBku7vOl2GvYTrKE7mT7B2KTxdfIZ1yu/2pUeC+Q4HZ4Zw= X-Received: by 2002:a9d:6543:: with SMTP id q3mr3986649otl.370.1556230488933; Thu, 25 Apr 2019 15:14:48 -0700 (PDT) MIME-Version: 1.0 References: <20190425161404.GS3137@localhost> <20190425214233.GX3137@localhost> In-Reply-To: <20190425214233.GX3137@localhost> From: Phillip Hallam-Baker Date: Thu, 25 Apr 2019 18:14:37 -0400 Message-ID: To: Nico Williams Cc: secdispatch@ietf.org, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000007b4af405876225b2" Archived-At: Subject: Re: [Secdispatch] [saag] The Mathematical Mesh X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 22:14:51 -0000 --0000000000007b4af405876225b2 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 5:42 PM Nico Williams wrote: > On Thu, Apr 25, 2019 at 05:12:00PM -0400, Phillip Hallam-Baker wrote: > > On Thu, Apr 25, 2019 at 12:14 PM Nico Williams > > wrote: > > > > Just to be clear: It is a similar approach to blockchain. The encoding > used > > is entirely separate. > > Understood. The point is that you end up with a cryptographic > append-only log. > Yep. > > The reason I was able to simplify the Mesh code was that I realized that > > all my application protocols could be implemented as instances of > > synchronizing containers between devices. > > Nice. > > > > Count on me as a reviewer, > > > > Thanks, that is greatly appreciated. The status of the current drafts is > > that the text is more or less complete, there are some missing images and > > multiple missing examples. > > Is that a request for review sooner than later? The current status is that the UDF and DARE drafts are essentially done. I do not expect to make major changes to those drafts in response to my work. I will of course expect to make changes due to the review cycle so if you are interested in reviewing, those are the drafts to look at. The next one I expect to be ready is the algorithms draft (8). This is pretty complete except that I have moved in work from elsewhere which needs attention and examples. Those will be the next examples generated by the code. If you want to see the scope of the work and how it hangs together, the architecture guide has the text but not the pictures or conversations. > --0000000000007b4af405876225b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 25, 2019 at 5:42 PM Nico Williams <<= a href=3D"mailto:nico@cryptonector.com">nico@cryptonector.com> wrote= :
On Thu, Apr 25= , 2019 at 05:12:00PM -0400, Phillip Hallam-Baker wrote:
> On Thu, Apr 25, 2019 at 12:14 PM Nico Williams <nico@cryptonector.com>
> wrote:
>
> Just to be clear: It is a similar approach to blockchain. The encoding= used
> is entirely separate.

Understood.=C2=A0 The point is that you end up with a cryptographic
append-only log.

Yep.


=C2=A0
> The reason I was able to simplify the Mesh code was that I realized th= at
> all my application protocols could be implemented as instances of
> synchronizing containers between devices.

Nice.

> > Count on me as a reviewer,
>
> Thanks, that is greatly appreciated. The status of the current drafts = is
> that the text is more or less complete, there are some missing images = and
> multiple missing examples.

Is that a request for review sooner than later?

=
The current sta= tus is that the UDF and DARE drafts are essentially done. I do not expect t= o make major changes to those drafts in response to my work. I will of cour= se expect to make changes due to the review cycle so if you are interested = in reviewing, those are the drafts to look at.

The next one I expect to be ready is the algorithms d= raft (8). This is pretty complete except that I have moved in work from els= ewhere which needs attention and examples. Those will be the next examples = generated by the code.

If= you want to see the scope of the work and how it hangs together, the archi= tecture guide has the text but not the pictures or conversations.

=

=C2=A0
--0000000000007b4af405876225b2--