Re: [Ace] EDHOC standardization
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. -- 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
Hi Ben, On 2018-11-03, 22:16, "Ace on behalf of Benjamin Kaduk" wrote: On Sat, Nov 03, 2018 at 05:51:55AM +0700, Michael Richardson 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? 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
