Re: [Ace] EDHOC standardization

[Benjamin Kaduk <[e-mail]>]

On Mon, Nov 05, 2018 at 09:16:54AM +0700, Michael Richardson wrote:
> 
> Benjamin Kaduk <[e-mail]> wrote:
>     >> John Mattsson <[e-mail]> 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