Hi Rene
Just to mention that I worked with Salvador and that the work he mention
it is part of a more general analysis we are doing with different
compression approaches for IoT deployment considering different networks
in EU projects like ANASTACIA and IoTCrawler and als for our spin-off
www.odins.es
Indeed your suggestion it is quite relevant as we are also interested on
these aspects and testing
regards
El 31/10/2018 a las 19:52, Rene Struik escribió:
Hi Salvador:
It would be interesting to explore what the impact is of lossless
compression (with side information, in terms of maintained state by
either protocol party) on sizes of message flows.
This could shed some light on the question as to how much, e.g.,
TLS1.3 message flows (or any other flows) can be squeezed and
un-squeezed "over the wire", thereby allowing a comparison of the
degree to which performance metrics are mainly due to formatting
schemes, such as [1]. I can imagine a breakdown as to how presumably
more favorable average compression ratio contribute to the mix vs.
different crypto schemes and security attributes. This would be a
useful exercise.
Rene
[1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017)
On 10/31/2018 2:27 PM, 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
[2] 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
[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: [email protected] <mailto:[email protected]>
Skype: salva.pf
On 31 Oct 2018, at 16:43, Benjamin Kaduk <[email protected]
<mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
Skype: salva.pf
_______________________________________________
Ace mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
--
------------------------------------------------------------
Antonio F. Skarmeta Gómez
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia
e-mail: [email protected]
Telf: +34-868-884607
fax: +34-868-884151
---
El software de antivirus Avast ha analizado este correo electrónico en busca de
virus.
https://www.avast.com/antivirus
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
