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

Göran Selander <goran.selander@ericsson.com> Tue, 19 March 2019 07:55 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 0B8111311F0 for <ace@ietfa.amsl.com>; Tue, 19 Mar 2019 00:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level:
X-Spam-Status: No, score=-3.321 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, URIBL_BLOCKED=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=ZuY1nyNP; dkim=pass (1024-bit key) header.d=ericsson.com header.b=R0JZQYp/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGQJL8GME_fD for <ace@ietfa.amsl.com>; Tue, 19 Mar 2019 00:55:41 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 BA4251311BF for <ace@ietf.org>; Tue, 19 Mar 2019 00:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552982137; x=1555574137; 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=QZirrTvURZcZXq7oCzGy65NS00db9hv0Fie7NT3xlFk=; b=ZuY1nyNPozlnGbZp4kmlZSOQBk6nxWSeQl3VpilWHww5J/fkP0sueMHF1HUvQPhP SXH36EgkNvIiyZ4dwAMvsP15pVAEichsXwj1OhHVheFr8M1Ow5ojWSkkVjO8OfZC 07SGrT8dmRsxgiG7Mlq5Sd/FS6sTjzM2QIfql/MEzpQ=;
X-AuditID: c1b4fb2d-2198b9e00000062f-9e-5c90a0795f44
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.52.01583.970A09C5; Tue, 19 Mar 2019 08:55:37 +0100 (CET)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB502.ericsson.se (153.88.183.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 19 Mar 2019 08:55:27 +0100
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 19 Mar 2019 08:55:27 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Tue, 19 Mar 2019 08:55:27 +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=QZirrTvURZcZXq7oCzGy65NS00db9hv0Fie7NT3xlFk=; b=R0JZQYp/jWDPnW+h13YWj5YBdIIUo8/hVS9jUj2+8G3B3r1T+Ew5CL0m84vPFJHkMZyqREvMbD2qy4YbztTdcELjs5BtPpoRgH3aLndYzB4RFS+dxfrnhiCdOopBF+PLhEnunPmX7cmt65o6bO32Pd1+rQmHBs7afaFUB7krJ/I=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3258.eurprd07.prod.outlook.com (10.170.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.11; Tue, 19 Mar 2019 07:55:25 +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; Tue, 19 Mar 2019 07:55:25 +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/PQCAADRKgIABOOiA
Date: Tue, 19 Mar 2019 07:55:25 +0000
Message-ID: <23E3AE30-3514-4A0A-BC24-DBB9CC84CBDE@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> <065BA537-5AC7-46A3-A08C-4403FC80E13F@ericsson.com> <60778d95-053b-1bbf-d7c8-c33ef490b255@gmail.com>
In-Reply-To: <60778d95-053b-1bbf-d7c8-c33ef490b255@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
x-originating-ip: [37.139.158.167]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cbbe1456-f8c9-4ba9-4f39-08d6ac403f35
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3258;
x-ms-traffictypediagnostic: HE1PR07MB3258:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <HE1PR07MB3258DAA6CB71E58CBBA14F5FF4400@HE1PR07MB3258.eurprd07.prod.outlook.com>
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(39860400002)(396003)(376002)(189003)(199004)(33656002)(7736002)(81156014)(476003)(105586002)(478600001)(486006)(97736004)(2616005)(85202003)(106356001)(68736007)(76176011)(85182001)(5660300002)(8936002)(82746002)(81166006)(8676002)(86362001)(6636002)(25786009)(99286004)(53546011)(6346003)(4326008)(102836004)(66066001)(316002)(6506007)(6512007)(236005)(58126008)(229853002)(6116002)(186003)(6246003)(53936002)(2906002)(3846002)(6306002)(54896002)(26005)(54906003)(110136005)(325944009)(6486002)(36756003)(256004)(14444005)(446003)(11346002)(606006)(93886005)(966005)(14454004)(6436002)(66574012)(83716004)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3258; 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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: EogS3rlJCfoMmfg5RHV+CW8zq67wvFH3gSjX8iyNGwI+2cFnUuLaJQP/2wnLPh4HboTbx29ATTYc+tBjx1nr2EWwH4euJZt1d3eDd/1+ZLYPapa5IBJJT6c/dwuHd8TtbIlovCsZL53bL8HV/x89TXIt9biM/qvPJB/gmhIkH71X3L5Dpv1PYMl2LjXAEC8URjyxZaQsvAiqCuOIU8orWHJqI1LGQP2lsDeMSrlv2N+zKUjGNQKq/6Rc0z/TMNxr/5WRw7RL49XH9ZNzupYv0CLduhh0xbxZzq7/aXIC4PXmk8O88PkhIJes34aEiCHIjlpF0kqQ5FBPMkpAA6nii3SA+NshNtR+2R6OSzFaE+OS8wahd1Y1xMrIH12LbSYvIUaTnfuqZiXix6aTo8nUKzH4ySPJMC/qij1mTB8LxDM=
Content-Type: multipart/alternative; boundary="_000_23E3AE3035144A0ABC24DBB9CC84CBDEericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cbbe1456-f8c9-4ba9-4f39-08d6ac403f35
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 07:55:25.6885 (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: HE1PR07MB3258
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGO/fe7V5Hk+N82T+1Dy3UktQ0CwN19kLNIozAkDJ06E2XumTX xPVJSyk1apChm4mVi0DN8CVMM7KlZuow+9B00dQ0X+jdQLOy2nZX+O33PP/n/J9z4DCkpE/g y6jUeaxGrcyWCUWUPqm9IER7Q5e89etFv6ilxUtk1J1mPRHVMDpLRTW+sgjiKEWH4Q2tMBqX CcW5oV7yMHlMFJ3OZqvyWU1YbKooc7inl8yt6icKzn/sJQvR4GOiDLkxgCPhm6VcUIZEjAT3 IBjvWSZ4sYig2WpG/0V3p57mhZGAyulW54TCOhJKjQuuBVcJKKt7TPHiLYIRcx/tqBHivTBR +NZZ6YUTocp2QeBgEufBbGsLcrCn3W/Sd7gyR8FmGhHyvA+KF/gMhQPAONZl9xlGjOUwNhLH dy1RMDtnc2bccAzoKr449yDsA0sDjQTfJQXrdK3r2RiMXcMkz94wP/XbeR9vHAZtlyco3pdB jbXJxevhZW054vkQtLywCh3FgMcQNAzP0PwgGPob5wQ8+8KnUcdhxs5Z8O5mAm/7g8X22bVn UAh/HkXoUKhh1fV4ToPqlTrkYDH2gOf6acpg30TizXCvM4yPbICK8kma501Qcr3GxQoofXiX Wp25gZh65M2xHJeTEbEtlNWo0jjutDpUzea1IPvvetL2M+QBani/y4Qwg2RrxWtUumSJQJnP aXNMCBhS5iWWx19JlojTldqzrOZ0iuZMNsuZkB9DyaTiXxKPZAnOUOaxWSyby2r+TQnGzbcQ GYpvV0q21NL15qAzH4Qn5P178g8cJJ54z8vGr8Vkmrp3fw9SDUQmSLdnBVY/jV4++SGxRL2z G8Yo2pAU2/5jY0C75epKlyW+6LIkJbze80igaL+7NfDWjiF/f5xKK8wzz45P3tcESl9PHQxO 066bMIOP+ynbYBHi0pcjW+VSGcVlKsODSQ2n/AvOMPetWQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/e7Ek7zHM9NjFPN7SkjFkHtztAj4>
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: Tue, 19 Mar 2019 07:55:45 -0000

Hi Rene,

There are two things which has a bearing on the topic we try to progress here:

1. assessing that a certain benchmark is relevant for a particular OSCORE deployment, and
2. assessing how well a solution performs with respect to the benchmark.

I made an attempt to explain one instance of item 1 – people can look up for themselves in [arch] or [0-touch] the protocol flow, the endpoints for the AKE (the Pledge and the JRC) and the role of the proxy (as in the Minimal Security protocol). This information is sufficient for defining the benchmark we are discussing here.

But at the end of the day, it is the users of OSCORE that should evaluate item 1, in this case the 6tisch WG. And this is what happened at the interim when a person active in 6tisch presented the quantification of the benchmark. The discussion about status of 6tisch drafts or potential new design requirement documents is probably better to have on the 6tisch mailing list than on these lists.

Göran

[arch] draft-ietf-6tisch-architecture-20
[0-touch] draft-ietf-6tisch-dtsecurity-zerotouch-join-03, section 2.4-2.5


From: Rene Struik <rstruik.ext@gmail.com>;
Date: Monday, 18 March 2019 at 15:15
To: Göran Selander <goran.selander@ericsson.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>;
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

Hi Goran:

Unfortunately, it is not clear at all. Details matter: one cannot simply wave a magic wand ("not yet defined, but is expected to", etc, etc.).

I am not a big believer in protocol design by email exchange. Security protocol design is hard, as is also evidenced by the document history of [1], where the initial document was produced in Sep 2016, adopted as WG document in Nov 2016, relabeled as another WG document sprout in Sep 2017 ... and now it is March 2019. Doesn't protocol design start on a white board, where one has an initial idea and then systematically work through issues, revisits assumptions, etc., rather than produce documents and then write the rationale after the fact?

I do not understand the current flurry of emails to push a particular design through: why not first coming up with a design requirements document that goes further than "byte-count" arguments?

One can do more analysis in the prelude to Montreal, but this is only meaningful if one does not cast things in concrete first and then ask for feedback, with some external "clients" (including the 6tisch use case that I questioned) as motivation. I do understand the motivation to claim a stake, but if intention is to reach a billion+ devices, I think the bar should be really high.

Ref: [1] https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/

[excerpt of what you wrote below]
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?

On 3/18/2019 6:08 AM, Göran Selander wrote:
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






--

email: rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363