Subject: [Ace] EDHOC standardization

From: Salvador Pérez <[email-masked]>
Date: Wed, 31 Oct 2018 10:12:54 +0100

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.
 
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-masked]
Skype: salva.pf

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Oct 2018 10:43:01 -0500

Hi Salvador,

> 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 o…

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

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Salvador Pérez <[email-masked]>
Date: Wed, 31 Oct 2018 19:27:08 +0100

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

> On 31 Oct 2018, at 16:43, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Salvador,
>

---

From: Rene Struik <[email-masked]>
Date: Wed, 31 Oct 2018 14:52:21 -0400

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:
> 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
> Email: [email-masked] <mailto:[email-masked]>
> Skype: salva.pf
>
>> On 31 Oct 2018, at 16:43, Benjamin Kaduk <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Salvador,
>>
>>> 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.
>>
>>> 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
>>> Email: [email-masked] <mailto:[email-masked]>
>>> Skype: salva.pf
>>>
>>
>>> [email-masked] <mailto:[email-masked]>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Antonio Skarmeta <[email-masked]>
Date: Wed, 31 Oct 2018 20:41:52 +0100

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ó:
> 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
>
>> [3] 
>> https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1
>> [4] 
>>>> 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.
>>>
>>>> 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.
>>>>
> email:[email-masked]  | Skype: rstruik

-- 
------------------------------------------------------------
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-masked]
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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Nov 2018 09:21:08 +0530

> (draft-selander-ace-cose-ecdhe) and want to share some experiences.

That's very cool.
Some questions for you!

    > 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),

What did you use for authentication?  RSA? ECDSA? EDDSA? PSK?
Were they raw public keys, or was it in a certificate?
Did you try a certificate in one direction and a raw public key in the other?
Did you offer more than 1 algorithm when you negotiated?

    > optimization, and relevant in many use cases where these parameters are
    > available through an out-of-band process.

If the list of valid algorithms is available securely by out-of-band
processes, then couldn't use this mechanism to do key agreement instead,
saving 100% of the bytes on the wire?  :-)

We need to do security parameter negotiation in order to be agile against
future algorithm attacks, and there will be algorithm attacks in the 20 to
40 year lifespans that we expect... and we need to leave space for replacing
the DH process with some QMDH process.  The CBOR encoding is really really
very nice for this, and I wish we had CBOR when we did IKEv2.

    > 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.

I don't see how LORaWAN has enough bytes available for even EDHOC.
I think that LoRaWAN needs a key agreement protocol that can be run once
while the sensor is attached to the installer's smartphone.  The important
thing is that one is able to use the key agrement protocol over IPs A<->B,
in order to setup a context that can be used between IPs C<-->D.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [