Re: [Ace] EDHOC standardization

Rene Struik <rstruik.ext@gmail.com> Wed, 31 October 2018 18:52 UTC

Return-Path: <rstruik.ext@gmail.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 8F68F130E62 for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 11:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UpRvUrPbcYlV for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 11:52:24 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3A1130E4B for <ace@ietf.org>; Wed, 31 Oct 2018 11:52:24 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id c6-v6so10457390iob.11 for <ace@ietf.org>; Wed, 31 Oct 2018 11:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=G4BYMj621WlGL/qe9jqFtsKWA52QhlJbFMtpJVY4TNM=; b=IKG/4chPJtz+aqodNU/3eDd85uPf69SBL+tFAQd93QTImR1YzSnx8i82t0Z0gJJ2rf rZZqhN64wWJgQczEtzrOFu7hGlGpOZFk+KkIToVZW+mcJKzuKyBDGRxhLiMfVAg2INAW nmW4KyEqQPo0JTdLww+/bb3xWys70XuYD1pAPw6hpADRgmFAvXGR0EKE9203Pr1xHuDW fczGxgxRYDt3qouLSa2ANuxXVWAxKl6uIK2v4aE+zaO6O8fUL+veDShBbpRpehPH5s2B HBWX/OkVmE3+uo+NYFgdXKMccMnO69W4h1H0QaK3mTpcM4Vv3g0fQ+bmrzQX9zgfRlXE Lhxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=G4BYMj621WlGL/qe9jqFtsKWA52QhlJbFMtpJVY4TNM=; b=OP+3+MG1kQi5MQ9epDAPTE94GgzRoScrsCotpsT92j7n/Gv1i6CQJFoJI+bIBXD8jc 2N7grWHU0L81JW2mEhXcU7KwPMfKUVhNk7IfIkJZH4/le6zqukgofgDO4ZpaeoehrzRB zG57YPvjIniP20kcANKB4cYAq9jwXFnD2D1IMz3HOhGpsrWSGcwNzufqEIxlzl15Bcoh vUNU20O89UZ9pL9MfxN+WO+ui//Y6SDoo5kyzqLF4CHIo748TxeFB/YTvDXsvXlOOKob eY8shXfu437ZCaFzZT3vuUTjLULg7JZQW4yHaT0LT6qvnUdLjtHYlgAOKNCFKhPU2PkX gS3w==
X-Gm-Message-State: AGRZ1gJS0UxogIBBo26YWW4fWUnY+XUaT7FD16sH4iIRojInlKodmC7q 7CgSc4Ln6haV5V9lvCQ0cEbfBTId
X-Google-Smtp-Source: AJdET5f1uCn39+xrQNaI7AHQ5pC2bqIsuU8l3reC0YJKr3TX3DsLoyS2A7YnwGrkRG6C8x9ZiuXWRQ==
X-Received: by 2002:a6b:2d7:: with SMTP id 206-v6mr2813363ioc.297.1541011943010; Wed, 31 Oct 2018 11:52:23 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id f18-v6sm7791072ioc.69.2018.10.31.11.52.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 11:52:22 -0700 (PDT)
To: =?UTF-8?Q?Salvador_P=c3=a9rez?= <salvador.p.f@um.es>, Benjamin Kaduk <kaduk@mit.edu>
Cc: ace@ietf.org
References: <B7A91B0B-5672-48D9-85A6-B8A8135305AC@um.es> <20181031154300.GK45914@kduck.kaduk.org> <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <3a7159e4-8c22-977d-fe75-bf3b2d33e7b1@gmail.com>
Date: Wed, 31 Oct 2018 14:52:21 -0400
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: <16DF6657-B39C-49C5-A584-19D0932CCB91@um.es>
Content-Type: multipart/alternative; boundary="------------727811DAE4EE40A92AF5A786"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/i5UtakP0yji8GT9_rRc-zy51z1k>
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 18:52:34 -0000

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