Re: [Ace] EDHOC standardization

Antonio Skarmeta <skarmeta@um.es> Wed, 31 October 2018 19:42 UTC

Return-Path: <skarmeta@um.es>
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 208181277C8 for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 12:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Z7S1NB7-cBdw for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 12:41:56 -0700 (PDT)
Received: from xenon42.um.es (xenon42.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 288FA128766 for <ace@ietf.org>; Wed, 31 Oct 2018 12:41:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id C916F218AA for <ace@ietf.org>; Wed, 31 Oct 2018 20:41:52 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon42.um.es
Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IqyEAy2fZi7w for <ace@ietf.org>; Wed, 31 Oct 2018 20:41:52 +0100 (CET)
Received: from [192.168.0.28] (62.175.47.223.dyn.user.ono.com [62.175.47.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: skarmeta) by xenon42.um.es (Postfix) with ESMTPSA id 6329C218EE for <ace@ietf.org>; Wed, 31 Oct 2018 20:41:51 +0100 (CET)
To: ace@ietf.org
References: <B7A91B0B-5672-48D9-85A6-B8A8135305AC@um.es> <20181031154300.GK45914@kduck.kaduk.org> <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es> <3a7159e4-8c22-977d-fe75-bf3b2d33e7b1@gmail.com>
From: Antonio Skarmeta <skarmeta@um.es>
Message-ID: <5198d09a-73a8-6fca-a467-705041f30385@um.es>
Date: Wed, 31 Oct 2018 20:41:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <3a7159e4-8c22-977d-fe75-bf3b2d33e7b1@gmail.com>
Content-Type: multipart/alternative; boundary="------------33ADE9B8C09B9F89298938BE"
Content-Language: es-ES
X-Antivirus: Avast (VPS 181031-4, 31/10/2018), Outbound message
X-Antivirus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/u3UHW77IcnH-LJ5kS4o9pLlV2zM>
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: Wed, 31 Oct 2018 19:42:00 -0000

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: salvador.p.f@um.es <mailto:salvador.p.f@um.es>
>> Skype: salva.pf
>>
>>> On 31 Oct 2018, at 16:43, Benjamin Kaduk <kaduk@mit.edu 
>>> <mailto:kaduk@mit.edu>> 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 <mailto:salvador.p.f@um.es>
>>>> Skype: salva.pf
>>>>
>>>
>>>> _______________________________________________
>>>> Ace mailing list
>>>> Ace@ietf.org <mailto:Ace@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>
>>
>>
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>
>
> -- 
> email:rstruik.ext@gmail.com  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> 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: skarmeta@um.es
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