There are so many things here which I badly want to thumbs up, that I don’t really even know where to start.
I agree completely with “hello world” needs to come with security batteries included. That means provisioning, onboarding, configuration, and debugging. There are many missing bits, but perhaps the most pressing missing bits are opinion: flexibility here is not a good thing because it leads a lot to confusion. One reason why I’m targeting my work for both FreeRTOS and RIOT-OS is because I really think that we need to get the security into the Adafruit target audience. Like Napster, the next IoT killer device will not come from someone who knows who the IETF is. {Napster guys didn’t know about network byte order, for instance}
RFC9031 is a good start. It’s taken too long to get to RFC because of dependency issues at the RFC-editor level. The K1/K2 key mechanism is appropriate for a vertical IoT operator: e.g., company X that makes some custom devices in house and then deploys them in their own infrastructure. To a very limited extent it supports larger customers of who direct order from a vendor… This is because of the need securely provision and transfer the symmetric keys to the customer.
So, this brings up to me, the provisioning aspect. If the customer is willing to one-touch the device with a cable, then the symmetric keys can be provisioned at that time. End-operator/customers who are buying bare hardware and doing their own flashing are in the position to that already. Most of the experimenters who use RIOT-OS are already in that position, which is why the RFC9031 model works well. And as you say, an EDHOC version of this would be nice, and I tried to provide for that upgrade in RFC9031.
The current BRSKI version of RFC9031 is draft-ietf-anima-constrained-voucher and draft-ietf-ace-est-coaps, and alas, it uses DTLS and it’s much fatter on the wire with many more round trips than RFC9031. Still, I hope to finish that code for ESP32 this year. (It’s partially in Rust)
I am trying (through medication induced brain fog) to do some practical design on flash layout for ESP32 such that we can provision IDevID into them in a way that is not erased by updates of firmware. The IDevID provisioning process could occur before final firmware, or after final firmware.
The hardest part, in my opinion, about getting RPL/RFC6550 to work is the debugging aspect.
We need a telemetry, and yeah, Shell over CoAP would probably help a lot. We effectively need a proxy version of it, such that one can reach out to the device you have a route to, and then, using it, use IPv6 LL to talk to the devices adjacent which are not, for reasons not yet known, inquire about their RPL status.
Having an 802.15.4 USB dongle that can speak to your smartphone, or some RIOT-OS device with an LCD screen and a SPEAKER such that one could, literally, use the sonar mode of ping, would also help people debug stuff. This needs to be a standard debug equipment the same way that RJ45 cable testers exist. https://www.amazon.ca/iMBAPrice-Network-Cable-Tester-Phone/dp/B01M63EMBQ/ref=sr_1_6?crid=ED8HDYNQRINZ&dchild=1&keywords=RJ45+cable+tester&qid=1630267293&sprefix=35ft+%2Caps%2C177&sr=8-6
I had a stack of CHIP CHIP (computer) - Wikipedia computers, including: CHIP (computer) - Wikipedia that I had added a 802.15.4 to, which I felt would make an ideal device, but CHIP is dead…
What I see is that we need to improve our flashing tools to make them able to deal with deploying (and updating) firmware with IDevID creation. I don’t quite know how this will look in the end. I do envision a situation with some kind of 8-port USB hub attached to something slightly more physically durable than a RPI {the small computers tend to fall off the table, because the cables are too heavy…}.
But, there are companies that do provisioning of devices in the factory today, and some interaction with them would be good.