Re: [Ace] EDHOC standardization
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 01 November 2018 03:52 UTC
Return-Path: <mcr@sandelman.ca>
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 CAEF1130E0E for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 20:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 bWo9dzMY04Hk for <ace@ietfa.amsl.com>; Wed, 31 Oct 2018 20:51:59 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C4C130E07 for <ace@ietf.org>; Wed, 31 Oct 2018 20:51:59 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [IPv6:2401:4900:16e3:794c:7862:56ef:35b3:3]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F8A51F42E; Thu, 1 Nov 2018 03:51:57 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id F19BC179E; Thu, 1 Nov 2018 09:21:08 +0530 (IST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?utf-8?Q?Salvador_P=C3=A9rez?= <salvador.p.f@um.es>
cc: ace@ietf.org
In-reply-to: <B7A91B0B-5672-48D9-85A6-B8A8135305AC@um.es>
References: <B7A91B0B-5672-48D9-85A6-B8A8135305AC@um.es>
Comments: In-reply-to =?utf-8?Q?Salvador_P=C3=A9rez?= <salvador.p.f@um.es> message dated "Wed, 31 Oct 2018 10:12:54 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 01 Nov 2018 09:21:08 +0530
Message-ID: <30535.1541044268@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/2NNVIRSQmRf9nIh-Cqp54COvMis>
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: Thu, 01 Nov 2018 03:52:02 -0000
Salvador Pérez <salvador.p.f@um.es> wrote: > we have implemented a previous version of EDHOC > (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), > especially with respect to length and number of exchanged messages. 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? > 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. 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. > 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. 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 [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
- [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