Re: [Ace] EDHOC standardization
"Owen Friel (ofriel)" <ofriel@cisco.com> Mon, 05 November 2018 17:07 UTC
Return-Path: <ofriel@cisco.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 742B3130DC2 for <ace@ietfa.amsl.com>; Mon, 5 Nov 2018 09:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level:
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KyZiIk3KB7G8 for <ace@ietfa.amsl.com>; Mon, 5 Nov 2018 09:07:03 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF90F127133 for <ace@ietf.org>; Mon, 5 Nov 2018 09:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9148; q=dns/txt; s=iport; t=1541437622; x=1542647222; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v9OSjbhd9nV23lmTlWjdQ0IB94wYlLViey1Nqk20yUA=; b=m4yMhNz64wQ4cg3nLOEYjlGxipRRNcCGvjuIT7LgBj+VPUG9+dBj+D0C JpHX/qJhBu3uAfxqqBlDbPLbpv86ITw3xVHT6+wPL3Fg/pNJVg2cNmIsj LH5DR0gwEJzxJOY0+CFyhEd/lRmSACUk4Igfuhjmn9YiBMxYysoOSH2QV I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AMAADrd+Bb/4UNJK1lDgsBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIEZn8oCoNsiBiMF4INg0CTbRSBZgsBARgNhEcCF4M6IjQNDQEDAQECAQECbRwMhToBAQEBAgEBASEROhAHBAIBCBEEAQEBAgIRFQICAiULFQgIAgQBEgiDGoF5CA+pL4EuhC0BAwIChWaBC4prF4FBP4ERghR+gnckAQECAYEZEgESATYogkWCVwKIdxKWKQkChmyKGyCCIY4/jQiKFwIRFIEmHThkcXAVO4JsCYIbAQIXiF0XhG06bwELi1iBH4EfAQE
X-IronPort-AV: E=Sophos;i="5.54,468,1534809600"; d="scan'208";a="196056650"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 17:07:01 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wA5H71Rp003366 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Nov 2018 17:07:01 GMT
Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Nov 2018 11:07:01 -0600
Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1395.000; Mon, 5 Nov 2018 11:07:00 -0600
From: "Owen Friel (ofriel)" <ofriel@cisco.com>
To: John Mattsson <john.mattsson@ericsson.com>, "salvador.p.f@um.es" <salvador.p.f@um.es>, "kaduk@mit.edu" <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EDHOC standardization
Thread-Index: AQHUcrwmU639Sl10oU+b3ygBlbENOKVBZ3Sw
Date: Mon, 05 Nov 2018 17:07:00 +0000
Message-ID: <cac4f57796b349a6813c48da6c57886e@XCH-RCD-012.cisco.com>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com>
In-Reply-To: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.220.232]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/k_uX6Wm2AGiQdw5qypuflbH6Tzg>
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: Mon, 05 Nov 2018 17:07:07 -0000
Hi John, Salvador, As EDHOC is used purely for key derivation with key exporting to the application for ciphertext exchange, does the lower byte count overhead of the EDHOC handshake vs DTLS1.3 really matter that much? Of course that depends on the amount of application ciphertext, but if there is a sufficient number of ciphertext bytes to be exchanged in one session, then DTLS + key exporting may make more sense than EDHOC + key exporting. Owen -----Original Message----- From: Ace <ace-bounces@ietf.org> On Behalf Of John Mattsson Sent: Friday 2 November 2018 14:56 To: salvador.p.f@um.es; kaduk@mit.edu; ace@ietf.org Subject: Re: [Ace] EDHOC standardization Hi Benjamin, Salvador While DTLS 1.3 have done a very good job of lowering the overhead of the record layer when application data is sent (see e.g. https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 for a comparison between different protocols), I do not think the handshake protocol is much leaner (is it leaner at all?). We tried to make an fair comparison between EDHOC and TLS 1.3 in the presentation at IETF 101 (see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00). Since then, we have significantly optimized the encoding in EDHOC and the upcoming version (-11) is expected to have the following message sizes. Auth. PSK RPK x5t x5chain -------------------------------------------------------------------- EDHOC message_1 43 38 38 38 EDHOC message_2 47 121 127 117 + Certificate chain EDHOC message_3 12 86 92 82 + Certificate chain -------------------------------------------------------------------- Total 102 245 257 237 + Certificate chains As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the same, so the numbers presented at IETF 101 should be a good estimate also for DTLS 1.3. Auth. PSK RPK -------------------------------------------------------------------- (D)TLS message_1 142 107 (D)TLS message_2 135 264 (D)TLS message_3 51 167 -------------------------------------------------------------------- Total 328 538 The numbers above include ECDHE. For handshake messages, my understanding is that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size. Cheers, John > 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 <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 PhD student in "Future Internet Networks: Infrastructure and Security” Faculty of Computer Science - University of Murcia Email: salvador.p.f@um.es Skype: salva.pf > On 31 Oct 2018, at 16:43, Benjamin Kaduk <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 >> Skype: salva.pf >> > >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
- [Ace] EDHOC standardization Salvador Pérez
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Salvador Pérez
- Re: [Ace] EDHOC standardization Rene Struik
- Re: [Ace] EDHOC standardization Antonio Skarmeta
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Göran Selander
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Owen Friel (ofriel)
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Ace] EDHOC standardization Jim Schaad
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- [Ace] (protocol flows) Re: [Lwip] EDHOC standardi… Rene Struik
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- [Ace] (details on use case scenario?) Re: [Lwip] … Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander