Re: [Ace] EDHOC standardization

Salvador Pérez <> Wed, 31 October 2018 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC4FB130E5D for <>; Wed, 31 Oct 2018 11:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V2x-vZQi9bQ7 for <>; Wed, 31 Oct 2018 11:27:11 -0700 (PDT)
Received: from ( [IPv6:2001:720:1710:601::41]) by (Postfix) with ESMTP id EE21F130DC9 for <>; Wed, 31 Oct 2018 11:27:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9ED8205EC; Wed, 31 Oct 2018 19:27:07 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id N3Eglg0p-zxA; Wed, 31 Oct 2018 19:27:07 +0100 (CET)
Received: from macbook-pro.home ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 4FB37204FA; Wed, 31 Oct 2018 19:27:07 +0100 (CET)
From: =?utf-8?Q?Salvador_P=C3=A9rez?= <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AEAB3B1C-24B6-40D2-8FB6-0987D5A915A8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 31 Oct 2018 19:27:08 +0100
In-Reply-To: <>
To: Benjamin Kaduk <>
References: <> <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [Ace] EDHOC standardization
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Oct 2018 18:27:17 -0000

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] <>
[2] <>
[3] <>
[4] <>

Kind regards,

Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia

> On 31 Oct 2018, at 16:43, Benjamin Kaduk <> 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:
>> Skype:
>> _______________________________________________
>> Ace mailing list