Re: [Ace] [Lwip] (protocol flows) Re: EDHOC standardization

John Mattsson <john.mattsson@ericsson.com> Mon, 18 February 2019 09:06 UTC

Return-Path: <john.mattsson@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 502C2130EE0 for <ace@ietfa.amsl.com>; Mon, 18 Feb 2019 01:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_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=IGDcuvkz; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Q9oKPu1y
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY7uXhlrycZl for <ace@ietfa.amsl.com>; Mon, 18 Feb 2019 01:06:23 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 91D32130EE6 for <ace@ietf.org>; Mon, 18 Feb 2019 01:06:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550480778; x=1553072778; 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=x6U7hPjS5+TYhn2LZ0MGAILC/MySITx6vKhXzSk7gDY=; b=IGDcuvkzgqHhJ8KKwA8rBtdz0GbTCRghtChfNtz6y3E/JR4Sm6eBVZ42uvf4L99g gev4Rxfrm5ei38uNZSN2AI2ViaAvTJ5UuWt08O61ZzTQdcuPxIAV2Ecy476aYNGY yvMWEeCsUMGvocgOT5IAIwUbYe4q2U1a6eSlwa8uzpA=;
X-AuditID: c1b4fb3a-5c9c29e00000672c-e7-5c6a758a1fd0
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7F.67.26412.A857A6C5; Mon, 18 Feb 2019 10:06:18 +0100 (CET)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 18 Feb 2019 10:06:18 +0100
Received: from ESESBMB501.ericsson.se (153.88.183.168) 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.1466.3; Mon, 18 Feb 2019 10:06:17 +0100
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 18 Feb 2019 10:06:17 +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=x6U7hPjS5+TYhn2LZ0MGAILC/MySITx6vKhXzSk7gDY=; b=Q9oKPu1y6apHFnXUEz5hx0y+bW4qwYcTIhYFNr9R+6PT6nXKpeFWRvWFGHNrSDX3XdM3YQ1db8fIpz88b1feJ69lWQbRGNDUs+1UVTcQ85pnr56+nlvQaAyqRLEnJ2jmlD+b4U9MbTxXXCif/txtxxUqvvwLdLJfr7bxNgv4abU=
Received: from VI1PR07MB4175.eurprd07.prod.outlook.com (20.176.6.24) by VI1PR07MB3853.eurprd07.prod.outlook.com (52.134.26.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.12; Mon, 18 Feb 2019 09:06:16 +0000
Received: from VI1PR07MB4175.eurprd07.prod.outlook.com ([fe80::bc9a:c323:2973:1a7d]) by VI1PR07MB4175.eurprd07.prod.outlook.com ([fe80::bc9a:c323:2973:1a7d%2]) with mapi id 15.20.1643.008; Mon, 18 Feb 2019 09:06:16 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "lwip@ietf.org" <lwip@ietf.org>, "ace@ietf.org" <ace@ietf.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Thread-Topic: [Lwip] (protocol flows) Re: [Ace] EDHOC standardization
Thread-Index: AQHUx2k0RaBfQFrA7k2GRKILzHguqg==
Date: Mon, 18 Feb 2019 09:06:16 +0000
Message-ID: <582F2909-0C33-403E-B87D-FAD45198AB37@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.15.0.190117
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [192.176.1.89]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 77b4039c-9a80-41e4-5134-08d6958056e2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB3853;
x-ms-traffictypediagnostic: VI1PR07MB3853:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: 1;VI1PR07MB3853;23:VN2WtUpBOZWxpDTfWfoI/5h7cudOIPn7Q8+R/Cv53KkmqQ4u3YaZF3/eMSZkQAIfUGB725cCP9y9JewL2vEaMGw0pW4uzkQD2K/sS505rfBoPtS16gFTkeU/rKYPhyPjC6JZkPpOTB15gEDCyN3jMR6UMsdBNSMsVuaqcmKdKWycNL6Mp4MaADpbIX9L2uEsSsYohn/M7aS26Z3TB4XrfmJ50sYSTBUus9SzZVYPQLn8Bumx/+6dp1EnpQp5nMZVKnBCuGqEsfZpMYokuyQ/n4RvSSTvM5vsDdrPbx76lT+ea+miBgwDMX31Dv9h4jr5aie/seh6i5DHS8iqRWtOZDs5/7pG2F+PJefEeremY9lR4dzW27tlmuJjK37rcWkRduStFRRLf+O++SJqSXT+Yh7xeqkOcMYeW9ssF07vbV2zdoyDoXxDvuNiJBYnSmzTacbgudML1Ssv+vlgYc8/6Ca+6BW+csVYJDyarC/RYq5ZgtIIKz0iOWQI92nr5lVC0/JQBmsyu57L2zWbg21Cqxo+Y+6OMmQFOoAxInXTlTOy2G1T+TaGo2cda3ocCxPw9kbjyhf8ZnfqS3ViN1I/esCM3UApcYpuB5VMxpUi4wNOPeDDPB5kpsPvDXxDT3kqX1TUrYF4H1vf+Z/eNfwUfjlSJOqM8jbaLlpAT7Qn1bfzQ/X28SvKMOKvb59CDvQn5y4vTMLoSquaktSXs5mMQeUSb3t4Sju6I6njr7skTwgGaHqPYtmjng9PXn2cgXXRY1BntXdvX929pUxzH0UQNLSwII1JyBBk8x41f6+Avnfv9f+8p8ICX/yt5pg8uD/iC+VBFsrxZyY6E4GOqSVZyjtltJrw1lEXlFmNQEGr6q4sSsqmq+hesxktX1qFQkdnukxqYR7YjONCMzPY1EfVMDXJOS4CGNKBPysH55Zf+k86vKnw+/Ky1f7UjvUilMS6/IrxxJDppKo+N9ssUyD35YPqkyogAx/2ZKcJOJ3oaicyRPe3bOLhMd+dTQ+yFUa1Jh5LcokS8k6a96PW1ClMcySgqcWdrGVHBkZfFvDvERnulDReB//miARDUBIkARZWRS238dmqHpuRTzBZmFDYNNK23wtai4s2PQ6EUVNGbHAKZoCFFCx2W3W2xgDSBQMnVWaQDnPW4+RPPun0DGGSNp/YKJkiW32rZj/iSvPiL7HPXgFWvCrc8h4psGVTEyuYFKyByW9o1YSbVnI14mvxz6UGmSqGL99BkTRt/2y+vY1ugjr/Yz5ft7NY5rG8Go/cP+sagcaQLdzxrzjrkFIzFg==
x-microsoft-antispam-prvs: <VI1PR07MB3853C96CEB859C68385542DC89630@VI1PR07MB3853.eurprd07.prod.outlook.com>
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(376002)(396003)(39860400002)(199004)(189003)(68736007)(5660300002)(256004)(3846002)(6116002)(2616005)(14444005)(44832011)(99286004)(2201001)(71190400001)(86362001)(14454004)(478600001)(5024004)(8936002)(305945005)(66066001)(71200400001)(83716004)(58126008)(53936002)(6512007)(6306002)(450100002)(316002)(82746002)(102836004)(25786009)(6486002)(6506007)(110136005)(186003)(26005)(97736004)(36756003)(106356001)(6246003)(486006)(81166006)(81156014)(8676002)(476003)(7736002)(33656002)(105586002)(229853002)(2501003)(2906002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3853; H:VI1PR07MB4175.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: kiHkcjg0mLxEQSc5LXgfZeDbke+BlJfWU2o/4Jw9yDnddnrv2vjjxR1uZcZMqe+dUlRNH3+IwUR+ROBPr/rvsNXSbEOsIjwA6JxMiM9TOJRmZ/C/kTAdcjUOhNchxvme7fhugzVxHjFWgX5BayI3X2HytoIP/MKDSchiYVubqTuVXEBJcT5Jqwc2wopzBdUPgj6RIzI+yvXuZmwgG2QR67eNovnZmTQdJH4KxwbWEEtWEY2+aB2TmBWmb2o419rQ22m0dgBFWNR5Z0eet+CUnX/L5Uq9RL6ZhpjsekHqso00316we4aee/ihmeCjhOkTCzTw1Igtuy6G5qJfydj1xazkPLPEEGv+lQJCumnhIsb6Xb3xe0ZfYsmhn3fqhCmblIdvbTgKRq0NhHOZSQUIv15eUChvCRIgM+POjL5XRxc=
Content-Type: text/plain; charset="utf-8"
Content-ID: <65B7196F7543DD4591576C2213CF7124@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 77b4039c-9a80-41e4-5134-08d6958056e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2019 09:06:16.3687 (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: VI1PR07MB3853
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe3bvndfZ4NmcerAMGxVkupkGioQZVhhUih96Ec2W3nyZznGv SvpFMVegsyYJtkUqMVmtiRZhFsNUNCsxMd8y6kPONCkNxJxiWbtei779/v/nnPPnHB6akJuo QDpHV8iwOk2eUiwhzWefFIVVFeWmhj/tCo12LxuJ6IZO32jH+AQVRyRYrauiJJQiOZjJ5OUU M6w69oIke+LLsJd+lLs8P+siytE7fRXypgEfgJXBRXEVktBy3IvgVsO6lyCWEdRMWkT/REWj kRSEVQSrMw6CFyQ2ETDWdHOzxySC9i4HJYgpBIbmz4iPEeNwuOMs98TQtAJzUDubwdu++Ajc MF4leFbgozAy9lwssAoqllpInkm8G+xXHop4luJDMLVi2BiJsD+4Xzs2fAIHwPvpRpGwEQar c4gQ2A/mXOsUz35YDWu2AVLoTQODoZ4SaoKh/968WOAgeNtYjQQ+CesVUxuXATyJ4IFraTMg BIxLb0iBA+HlcB8lFPXJoHahc3OSFswdrYhfGPB26FiMEuwZCpzGdJ7lmAFbiwGZkMry3w4W TweB90LrM7VgJ8DQRCUh8E6oq/7kZdk4hQxemafJJkTZkR/HcFx+VkSEimFzMjiuQKfSMYWP kOefdD9ei+lA3bOHexCmkXKrNO5Sbqqc0hRzJfk9CGhCqZAmp3ksaaampJRhC9LZojyG60Hb aFIZIP0pl6XKcZamkNEyjJ5h/76KaO/AcrSvxier9O4vwhZpy99xwn07OpFNsq+qVgYW2sIq 1Mr4kF1+MXFl57Uf+7/G2kfYNH+FS70mnQuPOi4brEu6L7ue0j50rBufcTYnupOrTWWVkUGJ nfXq0NOnvlX29p/7YU+otg46g7f4NLl+Z/iLvrdZg7T6D+b4Fz0XT42O77mmJLlszf4QguU0 fwDAXzWEIwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ>
Subject: Re: [Ace] [Lwip] (protocol flows) Re: 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 Feb 2019 09:06:25 -0000

Hi Rene,

These are interesting ideas. As you say, EDHOC is currently optimized for a minimum number of messages and bytes. Spreading out the bytes and computations could be beneficial in some applications. EDHOC is currently based on SIGMA-I. The four-message variant would be based on SIGMA-R with basically the same security properties. The difference would be that SIGMA-I protects the initiator identity against active attackers and the non-initiator identity against passive attackers. SIGMA-R does the opposite. I think protection models are needed in practice, but could also be solved by letting the initiator telling the other party to start SIGMA-I.

Party U                                                       Party V
|              C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U            |
+------------------------------------------------------------------>|
|                             message_1                             |
|                                                                   |
|                           C_U, C_V, X_V                           |
|<------------------------------------------------------------------+
|                             message_2                             |
|                                                                   |
|          C_V, AE(K_3; ID_CRED_U, Sig(U; CRED_U, aad_3) )          |
+------------------------------------------------------------------>|
|                             message_3                             |
|                                                                   |
|          C_U, AE(K_4; ID_CRED_V, Sig(V; CRED_V, aad_4) )          |
|<------------------------------------------------------------------+
|                             message_4                             |

I get the following message sizes for EDHOC when I apply SIGMA-R to
version -11 of EDHOC.

========================================================================
Flight                                #1      #2     #3     #4     Total
------------------------------------------------------------------------
DTLS 1.3 RPK + ECDHE                 150     373    213              736
DTLS 1.3 PSK + ECDHE                 187     190     57              434
DTLS 1.3 PSK                         137     150     57              344
------------------------------------------------------------------------
EDHOC RPK + ECDHE (SIGMA-I)           39     120     85              244
EDHOC RPK + ECDHE (SIGMA-R)           39      37     85     84       245
EDHOC PSK + ECDHE                     44      46     11              101
========================================================================

Regarding computations, I guess the main difference when it comes to asymmetrical crypto computations would be that Party V can compute a shared secret in between flight #2 and flight #3. Or are the any additional benefits?

SIGMA-I:

Party U                                                       Party V
                                                                    
generate a key pair
+-------------------------------#1--------------------------------->|
                          generate a key pair (can be done before #1)
                                              compute a shared secret
                                                                 sign
|<------------------------------#2----------------------------------+
compute a shared secret
verify
sign
+-------------------------------#3--------------------------------->|
                                                               verify

SIGMA-R:

Party U                                                       Party V
                                                                    
generate a key pair
+-------------------------------#1--------------------------------->|
                          generate a key pair (can be done before #1)
              compute a shared secret (can be done between #2 and #3)
|<------------------------------#2----------------------------------+
compute a shared secret
sign
+-------------------------------#3--------------------------------->|
                                                               verify
                                                                 sign
|<------------------------------#4----------------------------------+
verify

The optimization to split up the ECDSA Signature (R, S) and send R in the beginning is interesting, but as far as I understand, this only works for ECDSA and there is no similar trick for Ed25519 as both R and S depends on the message M.

SIGMA-I:

Party U                                                       Party V
|           C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, R_U          |
+------------------------------------------------------------------>|
|                             message_1                             |
|                                                                   |
|          C_U, C_V, X_V, AE(K_2; ID_CRED_V, R_U, S_U )             |
|<------------------------------------------------------------------+
|                             message_2                             |
|                                                                   |
|                  C_V, AE(K_3; ID_CRED_U, S_V )                    |
+------------------------------------------------------------------>|
|                             message_3                             |

SIGMA-R:

Party U                                                       Party V
|             C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, R_U        |
+------------------------------------------------------------------>|
|                             message_1                             |
|                                                                   |
|                        C_U, C_V, X_V, R_V                         |
|<------------------------------------------------------------------+
|                             message_2                             |
|                                                                   |
|                     C_V, AE(K_3; ID_CRED_U, S_U)                  |
+------------------------------------------------------------------>|
|                             message_3                             |
|                                                                   |
|                    C_U, AE(K_4; ID_CRED_V, S_V )                  |
|<------------------------------------------------------------------+
|                             message_4                             |


======================================================================================
Flight                                              #1      #2     #3     #4     Total
--------------------------------------------------------------------------------------
DTLS 1.3 RPK + ECDHE                               150     373    213              736
DTLS 1.3 PSK + ECDHE                               187     190     57              434
DTLS 1.3 PSK                                       137     150     57              344
--------------------------------------------------------------------------------------
EDHOC RPK + ECDHE (SIGMA-I)                         39     120     85              244
EDHOC RPK + ECDHE (SIGMA-R)                         39      37     85     84       245
EDHOC RPK + ECDHE (SIGMA-I)(ECDSA split S and R)    71     120     53              244
EDHOC RPK + ECDHE (SIGMA-R)(ECDSA split S and R)    71      69     53     52       245
EDHOC PSK + ECDHE                                   44      46     11              101
======================================================================================

I think these are interesting discussion topics. I will make an issue about them on GitHub.

Cheers,
John

Rene Stuik <rstruik.ext@gmail.com>; wrote:

>Hi John:
>
>When comparing protocols, it would be useful to protocol flows 
>optimization, as follows:
>a) optimized for parallelized online computations;
>b) optimized for minimization of message flows.
>See also slide 6 of my CFRG-83 presentation of March 30, 2012 
>(slides-83-cfrg-05 attached; I could not find CFRG records online).
>
>The current draft-selander-ace-cose-ecdhe-10 document considers 
>optimization b), which minimizes the number of message flows, but does 
>require each party to compute the shared key consecutively, rather than 
>in parallel (as in optimization a).
>
>With option a), if one really wishes to squeeze as much info into a 
>128-octet datagram, one can already send A's ephemeral ECDSA signature 
>key in message flow 1, thereby cutting down the
>size of the second message flow of the Sigma protocol depicted in Fig. 1 
>(https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#page-11) 
>by 32 octets. This tackles the 120-octet byte count for the second flow 
>of Fig. 1 quite simply, while leading to a 4-pass protocol flow (with 
>roughly 70/70/55/55 bytes in flows 1/2/3/4).
>
>Obviously, this presents a trade-off, but quite well be worth it in 
>settings where online key computations are quite slow on some platforms 
>and where scheduling (e.g., with TSCH) can now be done with less 
>consideration of the individual computational capabilities of devices 
>(since now one does not need to build-in a worst-case 2 x "key 
>computation back-off" for least capable devices, but can just use the 1x 
>contingency for this).
>
>The parallel version is depicted below.
>
>Party U Party V | C_U, X_U, ALG_1, UAD_1, R_Sig(U;...) | 
>+--------------------------------------------------------------------->| 
>| message_1 | | | | C_U, C_V, X_V, ALG_2, R_Sig(V; ...) | 
>|<---------------------------------------------------------------------+ 
>| message_2 | | | | S_U, AEAD(K_3; ID_CRED_U, s_Sig(U; CRED_U, aad_3), 
>PAD_3) | 
>+--------------------------------------------------------------------->+ 
>| message_3 |
>| | | S_V, AEAD(K_2; ID_CRED_V, s_Sig(V; CRED_V, aad_2), UAD_2)| | 
>+<---------------------------------------------------------------------| 
>| message_4 | 
>============================================================================>== 
>
>
>Flight                                #1         #2        #3    #4 	Total
>---------------------------------------------------------------------------->--
>DTLS 1.3 RPK + ECDHE                 143        364       212     -   	721
>TLS 1.3  RPK + ECDHE                 129        322       194     -   	645
>EDHOC    RPK + ECDHE                  37        120        85     -   	242
>--> EDHOC parallel flow		      70         70        55     55    250