Re: [Ace] EDHOC standardization

John Mattsson <john.mattsson@ericsson.com> Thu, 08 November 2018 06:14 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 AF43812D4ED for <ace@ietfa.amsl.com>; Wed, 7 Nov 2018 22:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=gaJjjRZK; dkim=pass (1024-bit key) header.d=ericsson.com header.b=FgvS580u
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 euCRfWjZ7P83 for <ace@ietfa.amsl.com>; Wed, 7 Nov 2018 22:14:12 -0800 (PST)
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 26BF6130E10 for <ace@ietf.org>; Wed, 7 Nov 2018 22:14:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541657641; x=1544249641; 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=q/woTtqoXBSQes3L8soecOucMmB5Unc8DWorxrZhp0Q=; b=gaJjjRZKyhkmQzlA1xGZ8R2ErnnomOREA/gvSBL1qZPDmE3jWFhReVSHdWv12wLA 9ksRw4HPHBkKJr+cl6r1qq2HC2TtXKUUNFI0bAW1XQevCx1o2/xNTSW8MrVL8DQf 7JjVJeyKbd7O1tyd/Q4Sve5D2+JEx+H/F9vciBVO1PQ=;
X-AuditID: c1b4fb30-39c4e9e0000043c4-09-5be3d42999fc
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.97.17348.924D3EB5; Thu, 8 Nov 2018 07:14:01 +0100 (CET)
Received: from ESESBMB502.ericsson.se (153.88.183.169) 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.1466.3; Thu, 8 Nov 2018 07:13:59 +0100
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) 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; Thu, 8 Nov 2018 07:13:59 +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=q/woTtqoXBSQes3L8soecOucMmB5Unc8DWorxrZhp0Q=; b=FgvS580u8wlvOL5WLHlpoIdWtoCgmwWtt3o6I4gCeEs5IAeL4NWEgmKpK7inzsuhFBsj2IgikbRRPbyHvEYG+2MV1tloPClvtatFaHBxzhOHlk0dMgVW/A+C2gx1DnNtyZWp077Emg3jIAMRlZkt+FTzcXzk2dukEdPFFBRkZNY=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB1658.eurprd07.prod.outlook.com (10.166.124.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Thu, 8 Nov 2018 06:13:57 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::fcb5:ca45:9e56:1910]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::fcb5:ca45:9e56:1910%2]) with mapi id 15.20.1294.034; Thu, 8 Nov 2018 06:13:57 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>, "salvador.p.f@um.es" <salvador.p.f@um.es>, "kaduk@mit.edu" <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EDHOC standardization
Thread-Index: AQHUcrwmx6N1o4AsH0uz6RMW3Bvpj6VBbnUAgAQRK4A=
Date: Thu, 8 Nov 2018 06:13:57 +0000
Message-ID: <3F39B50B-B273-4411-B828-C504DE6B139B@ericsson.com>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com> <cac4f57796b349a6813c48da6c57886e@XCH-RCD-012.cisco.com>
In-Reply-To: <cac4f57796b349a6813c48da6c57886e@XCH-RCD-012.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.11.0.180909
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [90.236.0.52]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB1658; 6:42GzKteK9V2tUvoiowbC8VADY00/aI0DqNFSF3fLK/TFt+3QaGcwKecVfdVAXQTNkq643LVkuIEIN9TTLI+j+Kb8HBcJf2JjxXNtZtbowgb8nPDyen2laj+WUKb5/dsdA5dRpvDCN1p3pqDWQWmWuWU6k3ISCjxUBUW+5C5QzyLAJYvhAI8u8fBweFXomkNoZaJvFnwEL2nBd6+peHSvYSiHuuEP5SXBnegq+KGtaDYM0y0UkoNojimoPNoQ8Mam1n8fydiD2Oia4XtaZQcgPZAW36jJND7HfXlQnJ6FYZfHtVLaJEzjt9op2JHzwtZom3kZOogbVMfs3DhOxB+VkYFpyg77vWv2FgcPyQ8S792+VnCuc+daErLycjYaMzNGcjaEGb8rKc+YzZKtBfSDJDcYC6Neh4bMN6pE4Gx9AhN1UewrkLW7hof0lUeO80BzaDornZLVigqwNLzLJwkJeQ==; 5:kpCJ0dtyMQrxGYRhSggKVp5A/debPRhx6tMA4vwJNY4PwUV8yTQUMXrD+/fO+UMaCMNYtmapteGcNOOG9e4tJ0EiQXSAuJIeB4Q7ZAxQmFYW13E3ng/eS3i04I8M6fZdrRVPuvfOa3RjI/u+8b6C/baX4apvlpfCbJGPu0byTmk=; 7:k7A2+RQ5Uxprzvcps/778YYh78WW8r6bG28RRt4QKbYXhEEi2pXfmk4708TV9i2e7UiE3rG3Oc2qdNEM/wemXjEvfbB6dhWsoQDimPWianVvzJYVMgNh2T6AjyOfUd/nBBmYHVNSrqrU4Mj23pV4Kg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 06b99e30-2f80-4ae3-ded8-08d645415e45
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB1658;
x-ms-traffictypediagnostic: HE1PR07MB1658:
x-microsoft-antispam-prvs: <HE1PR07MB1658517C8CB38018AAC847AC89C50@HE1PR07MB1658.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(240460790083961)(120809045254105)(163750095850)(5213294742642)(192374486261705)(95692535739014)(248295561703944)(37575265505322);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB1658; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1658;
x-forefront-prvs: 0850800A29
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(136003)(376002)(346002)(13464003)(189003)(199004)(52314003)(252514010)(86362001)(305945005)(81166006)(8676002)(110136005)(8936002)(7736002)(106356001)(81156014)(5660300001)(58126008)(486006)(256004)(3846002)(14444005)(476003)(6306002)(2906002)(2201001)(102836004)(6246003)(2900100001)(53936002)(2171002)(44832011)(6116002)(6512007)(316002)(2616005)(76176011)(11346002)(99286004)(446003)(25786009)(71200400001)(33656002)(2501003)(97736004)(68736007)(478600001)(82746002)(229853002)(83716004)(36756003)(66574009)(71190400001)(966005)(14454004)(66066001)(6486002)(186003)(26005)(105586002)(53546011)(6436002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1658; H:HE1PR07MB4169.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-microsoft-antispam-message-info: nYeG6eDV1SewVTtLrdeUqd+0I3T+yWFmnia04BloYP4cue+YR6/xbQZSpx7LW/hDxD4rBZMmPm4Il7todwxq1IITHugeIJQ7PSeshvolPBuDvd17GezeKXORX2XBa6XLIMHuRGYz3ArrrqUB6JjuyMdUBCsWVRRZmsb5CDD6KL6yyiDOuo/hrCfIAuhsmaggIad3V4qU9CZwzvxybSmXsCQWBH5uXCx9hJUqo+ijAnBiajecpgkrtieT80xg4ITTVbwivuK/qnCk22gIaiXNBmRYYz6ZgKimxOkUG/CPZ9h0iuPzh5A0itv5n8VRn2tzKA9IAcJZQ345EZFB7q7mtR9cPHxGIotSpD5FBrbfOck=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <777D049D4D1F9C4ABB828E37BD686AEF@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 06b99e30-2f80-4ae3-ded8-08d645415e45
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2018 06:13:57.4981 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1658
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUyM2J7ua7mlcfRBr+/cll8/9bDbLF840wm i1NXprBZNK+6yu7A4jHl90ZWjyVLfjJ5NJ05yuxx7mUbSwBLFJdNSmpOZllqkb5dAlfGtoUL WAreBFVsevWRsYHxTkAXIyeHhICJxIfPz5hAbCGBI4wSXz5adjFyAdlfGSUeP+tih3AWM0ls /buSEcRhEZjALHHv2hUmiMxkJok5S19AOQ8ZJU79Pc8OMoxNwEBi7p4GNpCEiMBsRomLc16D JYQFNCQ2dm0Fs0UENCWmvvjIBGFbSXy51wIWZxFQkVg24RRYnFfAXqJx30s2iAurJO5eXAwW 5xRwlbh09wNYPaOAmMT3U2vA4swC4hK3nsxngvhOQGLJnvPMELaoxMvH/1hBbFEBfYn5DzpY IXpjJVpbp7NC1MhLnDkzF8qWlbg0vxvsZwmBa2wSrdM+QyV0JT5MnQo11Fdiz9k17BBFxxkl 7u/6DJTgAHK0JJZsgzoiW+LulrlQg1YzSsxb1MUOkZCTWNX7kGUCo9EsJIfPAmpnBgbM+l36 EGEPiQ/vTjFC2IoSU7ofss8Ch4ugxMmZT1gWMLKuYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3Z xAhMPQe3/DbYwfjyueMhRgEORiUe3nlHHkcLsSaWFVfmHmKU4GBWEuH1OQYU4k1JrKxKLcqP LyrNSS0+xCjNwaIkzmvhtzlKSCA9sSQ1OzW1ILUIJsvEwSnVwNgsX8h0MuA7V/Bzj9tr/q87 +e9ezHO/T2vyHBgmtD1btr7/w6epjvbTXsyaubpNN187aa/de+vrcQmPZ/4TeLBrhXmwcKnm rOyavBOvmJQ139XW7f/V/tRb7qd9YZ1wcO+kEz6OnhoT27mmtXv3eS52eKfGPO/x5orpTfXX 7uSenjx/9f1HkyyVWIozEg21mIuKEwHYWtVjOQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/rG7WSs7Ud7WjohfmUd0i95cKrxA>
Subject: Re: [Ace] 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: Thu, 08 Nov 2018 06:14:15 -0000

Hi Owen,

In constrained radio deployments where throughput is the limiting factor, the number of bytes in the bootstrapping can make a huge difference.

The number of bytes is directly related to the minimum number of frames (in 6tisch each frame can typically carry around 80 bytes of payload) and therefore the number of round-trips and the time taken to bootstrap a new device.

If you have multiple devices bootstrapping at the same time, which is often the case, the relation between the number of bytes, the number of devices, and the bootstrapping time for the whole system is non-linear and even with a moderate number of devices, you quickly start to see bootstrapping taking forever or not finishing at all.

Cheers,
John

-----Original Message-----
From: "Owen Friel (ofriel)" <ofriel@cisco.com>
Date: Monday, 5 November 2018 at 18:07
To: John Mattsson <john.mattsson@ericsson.com>om>, "salvador.p.f@um.es" <salvador.p.f@um.es>es>, "kaduk@mit.edu" <kaduk@mit.edu>du>, "ace@ietf.org" <ace@ietf.org>
Subject: RE: [Ace] EDHOC standardization

Hi John, Salvador,
As EDHOC is used purely for key derivation with key exporting to the application for ciphertext exchange, does the lower byte count overhead of the EDHOC handshake vs DTLS1.3 really matter that much?  Of course that depends on the amount of application ciphertext, but if there is a sufficient number of ciphertext bytes to be exchanged in one session, then DTLS + key exporting may make more sense than EDHOC + key exporting.
Owen

-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Friday 2 November 2018 14:56
To: salvador.p.f@um.es; kaduk@mit.edu; ace@ietf.org
Subject: Re: [Ace] EDHOC standardization

Hi Benjamin, Salvador

While DTLS 1.3 have done a very good job of lowering the overhead of the record layer when application data is sent (see e.g. https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 for a comparison between different protocols), I do not think the handshake protocol is much leaner (is it leaner at all?).

We tried to make an fair comparison between EDHOC and TLS 1.3 in the presentation at IETF 101 (see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00). Since then, we have significantly optimized the encoding in EDHOC and the upcoming version (-11) is expected to have the following message sizes.

   Auth.               PSK       RPK       x5t     x5chain
   --------------------------------------------------------------------
   EDHOC message_1      43        38        38        38
   EDHOC message_2      47       121       127       117 + Certificate chain
   EDHOC message_3      12        86        92        82 + Certificate chain
   --------------------------------------------------------------------
   Total               102       245       257       237 + Certificate chains

As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the same, so the numbers presented at IETF 101 should be a good estimate also for DTLS 1.3.

   Auth.                PSK       RPK
   --------------------------------------------------------------------
   (D)TLS message_1     142       107
   (D)TLS message_2     135       264
   (D)TLS message_3      51       167
   --------------------------------------------------------------------
   Total                328       538

The numbers above include ECDHE. For handshake messages, my understanding is that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size.

Cheers,
John

> Salvador Pérez wrote:

Hi Benjamin,

	our results are included in a paper, which is under review for its publication.

Regarding the comparison between EDHOC and DTLS, we have employed the tinydtls library [1] since it is widely used to deploy DTLS in different IoT scenarios. Note that, at the moment in which the paper was written, such library did not offer support for version 1.3. Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3 ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]). Moreover, authors of EDHOC state that the message overhead of TLS 1.3 is much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH, the number of bytes in EDHOC is less than 1/3 when PSK authentication is used and less than 1/2 when RPK authentication is used, see Appendix E” [3-4]). Accordingly, we can claim that it is expected that DTLS 1.3 performs worse than EDHOC (at least, regarding message overhead) for the type of constrained implementations we are looking at.

[1] https://projects.eclipse.org/projects/iot.tinydtls <https://projects.eclipse.org/projects/iot.tinydtls>
[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5 <https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5>
[3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1 <https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1>
[4] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4 <https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4>

Kind regards,

--------------------
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador.p.f@um.es
Skype: salva.pf

> On 31 Oct 2018, at 16:43, Benjamin Kaduk <kaduk@mit.edu>du>; wrote:
> 
> Hi Salvador,
> 
> On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
>> Hello authors of EDHOC,
>> 
>> 	we have implemented a previous version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some experiences.
>> 
>> Our work so far has focused on implementation and evaluation of version -08 of EDHOC over CoAP using real IoT hardware. The obtained results show a significant performance improvement compared to other key establishment protocols, such as DTLS handshake (version 1.2), especially with respect to length and number of exchanged messages.
> 
> Are your results written up anywhere?  It would be great to see more 
> details of the comparison and the actual numbers.
> Unfortunately, I don't think that DTLS 1.2 is the best comparison -- 
> DTLS
> 1.3 should be seen as the current "state of the art" for DTLS, and is 
> expected to itself be leaner than DTLS 1.2, which might wash out some 
> of the results you've seen here.
> 
> Thanks,
> 
> Ben
> 
>> We have reviewed version -10 and noted the reduction of message length. Based on our experience, we propose that also removing the overhead due to security parameter negotiation could be an important optimization, and relevant in many use cases where these parameters are available through an out-of-band process.
>> 
>> Accordingly and taking into account that EDHOC provides a basic security functionality for any context where security needs to be enabled, we are currently considering the application of this protocol in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its integration with capabilities. We therefore would like to see the progress of EDHOC in standardization.
>> 
>> Kind regards,
>> 
>> --------------------
>> Salvador Pérez
>> PhD student in "Future Internet Networks: Infrastructure and Security”
>> Faculty of Computer Science - University of Murcia
>> Email: salvador.p.f@um.es
>> Skype: salva.pf
>> 
> 
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace