Subject: Re: [Ace] EDHOC standardization

From: John Mattsson <[email-masked]>
Date: Fri, 2 Nov 2018 12:31:16 +0000

Hi Salvador, Michael,

Regarding your comments on negotiation and out-of-band. We have gotten similar comments from Klaus Hartke regarding cipher suites and out-of-band. I added your comments to the open issue on GitHub

https://github.com/EricssonResearch/EDHOC/issues/57

We agree with you both, this can and should be optimized, but some kind 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. For the constrained deployments targeted by EDHOC, I think this might be the best trade-off between negotiation, overhead, and simplicity. While I think TLS 1.3 did the right thing to split up the cipher suites, I agree that for most constrained IoT deployments, the implemented algorithm(s) will often be the same for all nodes and fixed for long periods of time. As you stated Salvador, this would be an an important optimization. The message sizes would look as follows:

                 PSK       RPK       x5t     x5chain
   --------------------------------------------------------------------
   message_1      43        38        38        38
   message_2      47       121       127       117 + Certificate chain
   message_3      12        86        92        82 + Certificate chain
   --------------------------------------------------------------------
   Total         102       245       257       237 + Certificate chains

                 Figure 6: Typical message sizes in bytes

Cheers,
John

Michael Richardson 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.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Nov 2018 05:51:55 +0700

John Mattsson <[email-masked]> 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.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 3 Nov 2018 10:16:21 -0500

> 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?

-Ben

---

From: Göran Selander <[email-masked]>
Date: Sun, 4 Nov 2018 16:00:35 +0000

Hi Ben,

On 2018-11-03, 22:16, "Ace on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    
Michael may give his view, but the authors' proposal is to have a IANA register enumerating ciphersuites, and where value 0 is reserved for "pre-established ciphersuite". 

BR
Göran

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Nov 2018 09:16:54 +0700

Benjamin Kaduk <[email-masked]> wrote:
    >> John Mattsson <[email-masked]> 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.
    >>
    >> 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.
    >>
    >> 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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 5 Nov 2018 03:38:07 -0600

> 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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Nov 2018 10:41:43 +0700

> idea is that any given node is only going to do 1 or 0 and not both?  Maybe

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.