Salz, Rich <[email protected]> wrote: > Sorry for the late response, I hope it’s still useful even though I am > not normally involved with IoT things.
> I think this document is very good. It makes reasonable requirements
> and suggestions, that seem to have the appropriate trade-off for
> security and device capabilities (e.g., CCM8).
I'm really glad to hear this.
> I think it was a VERY SMART move to stay away from post-quantum for now.
*for now*
Given the rate of walled-garden [device-to-vendor's-cloud-only],
(residential) IoT device abandonnement, I think a movement to quantum-safe
algorithms might be easier deployed here than in other spaces...
(I don't know an appropriately strong irony emoji to insert here.)
CSA/MATTER has no quantum-safe storey that I see, and no upgrade path.
In the automotive space, the lifespan will be a concern, but they aren't
going to read this document, and they have their own specifications already.
The onboarding storey there is poor from what I can tell.
In the industrial IoT space, I'm also concerned. They will be 'saved' by far
more extensive use of wires, and where 802.15.4 networks exist, such as
ISA100, the airgap nature will help. And the lack of onboarding means they
were using static symmetric keys for the network layer.
In the building automation space, I'm concerned.
There are fewer consortia, and the people producing equipment are less
network focused.
I propose that we wait for LAMPS to finish composite-kem, and then we start a
quantum-safe version of iot-profile. So let's say Spring 2026.
It would be fantastic if we could get the various IoT cloud-side people
involved. Azure, Amazon, ...
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
