Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

Göran Selander <goran.selander@ericsson.com> Mon, 18 March 2019 10:08 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A52131140 for <ace@ietfa.amsl.com>; Mon, 18 Mar 2019 03:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.322
X-Spam-Level:
X-Spam-Status: No, score=-3.322 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Q3sZrPNY; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OLSvaUsZ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZMkYLz6i6Nr for <ace@ietfa.amsl.com>; Mon, 18 Mar 2019 03:08:30 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8454113111F for <ace@ietf.org>; Mon, 18 Mar 2019 03:08:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552903705; x=1555495705; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pwD6Ye2o4UhlPzH6pvlriCYu0kn7xwiqG9WHqVVkN4c=; b=Q3sZrPNYlb5ozIi45xAbPLkpGKgR9UpIiUx2shHMxGOtjGZt3I5Dmc2df2YEsqeD w/IPk70RwM6ODOJeDAAdOBdo1y5R6QaHBQWWPMhNaFd5ryMWNxFPxV2qabs3+CEh s3EDdxbfOGPeW2V0p9sb1Iv6D7HNBN7GYGVHnFT3qN4=;
X-AuditID: c1b4fb30-41b3a9e00000355c-53-5c8f6e1908a4
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.29.13660.91E6F8C5; Mon, 18 Mar 2019 11:08:25 +0100 (CET)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 18 Mar 2019 11:08:23 +0100
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 18 Mar 2019 11:08:23 +0100
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 18 Mar 2019 11:08:23 +0100
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=pwD6Ye2o4UhlPzH6pvlriCYu0kn7xwiqG9WHqVVkN4c=; b=OLSvaUsZxx3pNVqCMZmAKpxjQ2Jco+K/JXLS3I+qQosr+uJtSdBtReDawjK4hkdtUcas6O5y6clM99GIvi/aLi41lgg5VB/J1xgX3QDNFT+BYGpmvUdGf7509jwP0lvL4+Z23WD+FXISA1yTYJs2ijjDClY2e5KcMZ+qimp46To=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB4153.eurprd07.prod.outlook.com (20.176.166.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Mon, 18 Mar 2019 10:08:21 +0000
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::ec09:4e6b:509a:c86e]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::ec09:4e6b:509a:c86e%2]) with mapi id 15.20.1709.015; Mon, 18 Mar 2019 10:08:21 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Rene Struik <rstruik.ext@gmail.com>, John Mattsson <john.mattsson@ericsson.com>
CC: "secdispatch@ietf.org" <secdispatch@ietf.org>, 'Benjamin Kaduk' <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
Thread-Index: AQHU01ym8OWGcqP/kkC34Q6dVV+srKYMz9OAgAR/PQA=
Date: Mon, 18 Mar 2019 10:08:21 +0000
Message-ID: <065BA537-5AC7-46A3-A08C-4403FC80E13F@ericsson.com>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com> <20181103145857.GG54966@kduck.kaduk.org> <7F78CC92-5C48-4BFC-8087-E25D4D95A74F@ericsson.com> <000001d481ae$57cd4530$0767cf90$@augustcellars.com> <B119A1D8-08B5-431E-BB16-35D84AA6F6CB@ericsson.com> <8155ccb8-6b44-cd49-caae-8915ef0cef7d@gmail.com> <89483a94-8c12-9fc7-a4ed-75fb250beb14@gmail.com> <985573C6-A4A6-4CDE-BDC6-6E53EE80C025@ericsson.com> <087b4e56-fed8-ea17-5d02-882ff34665ad@gmail.com> <2cd05b52-c0de-18b1-c152-cc8b7c4f887b@gmail.com>
In-Reply-To: <2cd05b52-c0de-18b1-c152-cc8b7c4f887b@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [95.192.203.39]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1d50fc36-8eb5-4a2e-d271-08d6ab89a6e6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4153;
x-ms-traffictypediagnostic: HE1PR07MB4153:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <HE1PR07MB4153FC63B10609BC0EADD67DF4470@HE1PR07MB4153.eurprd07.prod.outlook.com>
x-forefront-prvs: 098076C36C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(376002)(39860400002)(346002)(189003)(199004)(83716004)(71190400001)(71200400001)(3846002)(6636002)(256004)(14444005)(2906002)(66574012)(606006)(85182001)(110136005)(81166006)(81156014)(82746002)(8936002)(6436002)(6486002)(7736002)(58126008)(97736004)(36756003)(99286004)(54906003)(8676002)(25786009)(6116002)(229853002)(33656002)(6512007)(106356001)(85202003)(26005)(4326008)(68736007)(76176011)(93886005)(186003)(6306002)(316002)(476003)(2616005)(486006)(478600001)(236005)(86362001)(6246003)(14454004)(105586002)(5660300002)(102836004)(66066001)(6506007)(53546011)(53936002)(11346002)(446003)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4153; 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: rlbUURvSWyWAa0T7YZ5OHq5aTNhINN2GtZsGe9S23swKLGARwZJnXGfIjLdgR1nTu8H+xiNCf5HCANoIp1SElIlJkiHP1dZXYZj4SgEJEz+a32uUfunM8Eks+wFRYEhoZsEBquca8SEw2g7XfPRoy8kC7a7bgRfpWXEoitQ1TGz+b89FhMjAOqGloUlO8PnPBOauB9rtFsaqIG7DH9GmIcNrdjWkVSZZoW4KpRxP40p1inF1u4SuGrRePvKPwlz+cwzFbscLedbkGJ4j3GfyTU2XlwUlwGN+0uX4GpqW9GbguGjRiwNJFL7S6IZHNmWS9NY0bMkwq1ltW4DLX+4NDM8JM2qJ57+CIgH7Tcfvq7HMOQVl52I2tyaS/SLvMl+sek8gRvNUDHK90ROh+WFdxxhvfj2ad1RFEbFSuqWICt8=
Content-Type: multipart/alternative; boundary="_000_065BA5375AC746A3A08C4403FC80E13Fericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d50fc36-8eb5-4a2e-d271-08d6ab89a6e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2019 10:08:21.7107 (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: HE1PR07MB4153
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGOffebXejwXFqvs76w0WQRmoStD50CmlKSB9QRJi69KbinLr5 kWJlphUqKqjpZqHWSiqbNlc6sUgzrLBMjdTEb9MEDcNQYpptuwv87/c+73Pe87yHQ5OiLo6Y jlemMiqlXCHhCijN2ZasPa7KknCfbqObdHWliJTWP9MQ0idDc5S04esgJ4AKMWlHeSE63R8i JLfnLXmCPCc4HMMo4tMZlbd/lCDuU/EtXnLec3RpXKPl5KDqJlSA+DTgfaD5+YIqQAJahLsQ 9C2/IawNEV5BsN57nm1YuLj6AckWOgJm8qsIa0HhUhIM02bEdsoIaLk/xGOLKQTXm9o41mFc fAQmcqZsg53waagau2nTSZwKc80GWxJHi67XmOyeMzDW2cctQLSFD8LIrMwqU3gnGPWLPCsL sQy0pT94bNZiCrpqMq3Mx35wTz9u0xHeCqsfGgj2Khf4NlNDsEtj0LX3kiw7w/z0X1scZ+wN xuIJij0bAbn6HC7rcYeR5Rb7g22H/ppCZI0GOAw0hkjruoCHEQzrK+1+T+g3zdrvEkNd728e ywkwWblhn7MNBt7VEaXIS7spHsvRMNzYSmltazrAe82MhWmL7gGNbd6sxR3KCyd5LO+C/Dt3 7RwCEwNzaLOnFtGPkbOaUV9IjPX19WJU8dFqdZLSS8mkGpDlb3UYzT6taH4usBNhGkm2CP3i S8JFHHm6OjOxEwFNSpyEslCLJIyRZ2YxqqRIVZqCUXciN5qSuAjXRA7hIhwrT2USGCaZUf3v EjRfnIMUeRKjzAmawxZMaze+76BaF3Zf6f6VaGY+VixdG+1ZCpXXkk1lUS7coxuvBi7u75ga DCAyrl4OjlhcPT7pWB0c9CV/ZKM78mSgKTssQ/zylOTRU0eB/3KUuD4t6xD/WPDGenm4q9SD KfrcbpiuSL49HWROKUvJdn1Ypyt4faDeV0Kp4+R7PUmVWv4PTmBzFVcDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/G3WuM09tMctAb59QcfWQcXHvcPg>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2019 10:08:46 -0000

Hi Rene,

Sorry for slow response to your mails.

From: Rene Struik <rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com>>
Date: Friday, 15 March 2019 at 15:28
To: Göran Selander <goran.selander@ericsson.com<mailto:goran.selander@ericsson.com>>, John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>>
Cc: "secdispatch@ietf.org<mailto:secdispatch@ietf.org>" <secdispatch@ietf.org<mailto:secdispatch@ietf.org>>, 'Benjamin Kaduk' <kaduk@mit.edu<mailto:kaduk@mit.edu>>, "ace@ietf.org<mailto:ace@ietf.org>" <ace@ietf.org<mailto:ace@ietf.org>>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

Hi Goran:

As you recall, I suggested to look at some details of 6TiSCH enrollment (see my message of March 4, 2019 [1]). During the SecDispatch interim of March 5, 2019, this was provided as one use case scenario [2] and reiterated in your email of yesterday, March 14, 2019 [3]. Nevertheless, details on how this could be realized in practice are still missing.

I had another look at the 6TiSCH minimal security draft [1] (now in 2nd WGLC) and the "zero-touch" write-up [5] -- which you both referenced in your email [3] of yesterday.

To my understanding, the intention with 6TiSCH is to reuse the protocol flows of [4] to implement a public-key based enrollment scheme in the future. This seems to be what [5] aims for, if I try and read in between the [still unwritten] lines, and the impression I got from some people. From looking at the protocol details, though, I do not understand how this can be done in practice. This begs the question what I am missing here.

Hence, my question of March 4th on details of use case scenarios still stands. In fact, I do not see how one could implement EDHOC on top of [4], even if one only uses symmetric-key only variant of EDHOC.

If you could shed some light on this, this would help. Or, should we simply abandon that use case as being unrealistic at this point?

6TiSCH minimal security [4] specifies how a Pledge joining a new network communicates using CoAP with the JRC via a Join Proxy and over additional hops. The proxy operations in the Join Proxy incurs certain overhead in the communication between Proxy and JRC. The exact procedure for the zero-touch is not yet defined, but it is expected to reuse features of the Join Proxy in the minimal security setting. The benchmark in [2] is based on this setting but replacing the OSCORE protection of CoAP with the AKE protocol messages carried over CoAP. Is it more clear now?

Finally, your email [1] suggests "reports of massive breaches with PSK provisioning systems". If so, I would strongly suggest having another look at [4] and commenting on this.

I’m not sure exactly what you want me to comment on. Clearly there are weakness with PSK based systems w/o PFS. But PSK w/o PFS is still used for various reasons, including inability to deploy better security. This inability may be real due to performance limitations or only perceived, for example due to unawareness of intermediary provisioning schemes between PSK and certificates, but in any case PSK w/o PFS is clearly a better alternative than no security at all. One purpose of the work we discuss here is to lower the threshold for PFS.

You mentioned in a previous mail other limitations in the multi-hop setting besides message sizes, and that is indeed true - this is just one benchmark. Is there some specific characteristic you want to highlight in this context?

RS>> My 10-hop enrollment use case was aimed to force consideration of
not just abstract "protocol flow arrows", but also effects on the
network and its actors. A simple byte-count is not enough...
<<RS

Göran

Ref:
[1] Details on Use Case Scenarios, email RS of March 4, 2019. Seehttps://mailarchive.ietf.org/arch/msg/ace/On0iIFAb_OWeBqLjlryi1rBHwhk
[2] Slides on EDHOC during SecDispatch meeting of March 5, 2019. Seehttps://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
[3] Pitch for EDHOC, email Goran Selander of March 14, 2019. Seehttps://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
[4] draft-ietf-6tisch-minimal-security-09
[5] draft-ietf-6tisch-dtsecurity-zerotouch-join-03