[Secdispatch] Regarding the EDHOC IETF Developments

[Hannes Tschofenig <[e-mail]>]

Hi all,

I was negatively surprised about the conclusions the area directors have taken with regard to the proposed work on EDHOC.

I have therefore used this as an opportunity to reach out to my co-workers working on IoT deployments and our embedded implementations to collect their feedback. They have not run into performance problems with the use of DTLS & TLS 1.2 today (and our technology is used in lots of IoT environments). Our Mbed teams are continuously working on enhancements, including RAM and codesize improvements, for the security stacks and also for the IoT operating systems. Things work fine today even though some of the newer IETF work in the security area has not yet been utilized. Embedded system development takes time.

The recent work on cTLS gives me the impression that performance optimization can be gained incrementally. That's very good news for those companies who have made several years of investment in those stacks. With our commitment to build a high-quality embedded TLS/DTLS tack (along with the crypto) we are obviously interested to see further work in that direction. I have started with a prototype implementation of the cTLS draft. It was a simple exercise without many code changes.

I understand that nobody wants to hear that they shouldn't standardize their favourite solution. No IESG member likes to convey that message because they would like to get re-elected. Working group chairs obviously don't like to communicate such a message either. In the end, we have lots of solutions in the hope that the "market will figure it out". Just look at how many solutions for communication security we have (see Section 4.2 of draft-irtf-t2trg-iot-seccons-16) or how many different ways to provision credentials (see draft-sarikaya-t2trg-sbootstrapping-06 and we are adding more -- https://bit.ly/2v4p7rn) there are. The IETF has become really efficient in publishing specs. That's great. It is a pity that the embedded community is not that fast to deploy them.

Normally, we do not care if someone proposes yet another solution. Unfortunately, for IoT-related stuff we spend a lot of time explaining why certain solutions are neither available in IoT operating systems, why they are not doing what they claim to do, or why the problems are actually somewhere else. We are worried about the collateral damage that results from standardizing EDHOC.

Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.