Re: [Ace] EDHOC standardization

[Michael Richardson]

Benjamin Kaduk  wrote:
>> > Are you proposing that the management of the 0/1-to-algorithm mapping
>> > be managed on a per-deployment basis or by the IETF?
>>
>> I think that the existing proposal was that 0 means "negotiated 
out-of-band",
>> which implies that it's a per-deployment basis.
>>
>> I'm proposing that instead of having 0 mean "some local default",
>> I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some 
other
>> local default 1", which lets the default be updated without a flag day.

> That feels like a potentially awkward provisioning problem.  I guess the
> idea is that any given node is only going to do 1 or 0 and not both?  
Maybe
> that helps.

I don't think you get it if you think it's awkward!
Any firmware implements 0 or 1, correct.
[I'm not a fan of such a system. I also don't think it is small enough for
LoRAWAN either]

When a new choice is hard coded into that closed vertical system (via
"out-of-band"), this choice would be baked in at the next firmware update.
(There are many ways to do this of course. Throw dip switches if you like)

Having both 0 and 1 lets the firmware be incrementally updated, otherwise the
operator either has a flag day, or has to keep track of the parameters on an
per-device basis.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] EDHOC standardization

[Owen Friel (ofriel)]

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  On Behalf Of John Mattsson
Sent: Friday 2 November 2018 14:56
To: salvador@um.es; ka...@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  43383838
   EDHOC message_2  47   121   127   117 + Certificate chain
   EDHOC message_3  12869282 + 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
   
   Total328   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 

[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@um.es
Skype: salva.pf

> On 31 Oct 2018, at 16:43, Benjamin Kaduk ; 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? 

Re: [Ace] EDHOC standardization

[Benjamin Kaduk]

On Mon, Nov 05, 2018 at 09:16:54AM +0700, Michael Richardson wrote:
> 
> Benjamin Kaduk  wrote:
> >> John Mattsson  wrote: > of negotiation is
> >> still needed. The current plan for the next version > is to introduce
> >> cipher suites and to let the cipher suite with value 0 > indicate that
> >> algorithms have been negotiated out-of-band.
> >>
> >> I agree with the idea that some common default should be very easy to
> >> refer to, but I don't like the idea that the gateway has to remember
> >> what the out-of-band "default" is on a per-device basis.  I would say
> >> that we need at least 0/1, so that we can say that it's the current vs
> >> the "new" default.
> >>
> >> If you consider the case where the sensor is on very low bandwidth
> >> connection (I would say LoRaWAN, but I am not well qualified in that
> >> space).  The sensor gets visited every two or three years by a
> >> technician (if only to make sure that the sensor is still where it is
> >> supposed to be).  While there new firmware updates are applied, and as
> >> a result the algorithm defaults are updated.  During the cycle, some
> >> devices are updated and some are still old.
> 
> > Are you proposing that the management of the 0/1-to-algorithm mapping
> > be managed on a per-deployment basis or by the IETF?
> 
> I think that the existing proposal was that 0 means "negotiated out-of-band",
> which implies that it's a per-deployment basis.
> 
> I'm proposing that instead of having 0 mean "some local default",
> I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other
> local default 1", which lets the default be updated without a flag day.

That feels like a potentially awkward provisioning problem.  I guess the
idea is that any given node is only going to do 1 or 0 and not both?  Maybe
that helps.

Thanks,

Ben

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace