Re: [Secdispatch] Regarding the EDHOC IETF Developments

[Benjamin Kaduk <[e-mail]>]

Hi Hannes,

On Sun, Apr 14, 2019 at 12:34:46PM +0000, Hannes Tschofenig wrote:
> Hi all,
> 
> I was negatively surprised about the conclusions the area directors have taken with regard to the proposed work on EDHOC.

I'm not sure that you think the conclusions we reached are the conclusions
that I think we reached, so let me try to say a bit more about my
perspective of where things stand.

> 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.

You and your colleagues' work on (D)TLS, mbed TLS, and such are greatly
appreciated.  But I hope you can sympathize with the statement that "there
is IoT, and then there is IoT" -- the term means different things to
different people.  So what Roman and I tried to do with all the information
that came out of the interim was to pull togther some of the concrete scope
and requirements information that had been presented.

In particular, we tried to give specific references to concrete scenarios
like the 6TiSCH multihop join scenario (which seems to impose a fairly
sharp limit on the frame count) and the LoRaWAN duty cycle constraints.
We've already seen some follow-up questioning whether these constraints
apply in all the stated scenarios, and I welcome the greater clarity that
those discussions are providing.

> 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 don't think anyone is arguing that something like cTLS is not worth working on.
But that's not really topical to the question of what to do for the
specific concrete scenarios that were presented at the interim, especially
when we are getting requests from other WGs to get something "good enough"
out quickly instead of delaying indefinitely to get closer to perfection.

> 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.

I'm happy to tell document authors that their document is unlikely to get
published in the case where it doesn't solve a real problem with real use
case.  The numbers we've seen presented so far haven't really convinced me
that this is the case for the concrete scenarios that were presented at the
interim, though.  (But there are still a couple related threads ongoing, I
suppose, so we can see how they progress.)

-Ben

> 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.

> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch