What is the project status and what LwM2M versions are supported?

[eabase]

1. What is the project status?
2. What LwM2M versions are supported? (LwM2M v1.1 and/or v1.2 ?)
3. What DTLS versions are supported? (1.2, 1.3)
4. Is this project still being maintained?

[rettichschnidi]

(edited your message so that I can reply to it more easier)

1. Revival has been started, but going on much slower than anticipated.
   At Husqvarna, we took part in the revival because we need Wakaama in an upcoming product. Luckily for us (and bad for Wakaama), we figured that most of our needs could already be served by the existing Wakaama code and therefore our focus shifted to other, more pressing areas. The pendulum is swinging back now however, as we need new features (> LwM2M 1.0) and therefore are, once again, more able and motivated to improve Wakaama.
2. AFAIR: 1.1 is and 1.2 not at all supported. @mlasch, please correct me.
3. I do not know, never had a (deep) look at it.
4. Surely not well maintained as of today, but we (@mlasch, me and others) will try to do more/better in the future. My personal goal was and still is to improve the tooling, documentation and testing, so that new people can join easier and improving the code can be done more safely.

[sbernard31]

Concerning point 3) about DTLS,

AFAIK, Wakaama core library doesn't depend directly to any DTLS library.
There are some examples in this repo which are using tinyDTLS and so running DTLS 1.2.
But in theory, you should be able to use any DTLS implementation and so any version of the protocol.
(See some related discussion about it : #623)
By the way, there is a open PR about using mbedtls in example too, see #626.

At LWM2M level, the specification v1.0 and v1.1 doesn't mention DTLS v1.3.
Asking to OMA it seems this should be doable to use it but for now there is no recommendation provided : see OpenMobileAlliance/OMA_LwM2M_for_Developers#540

In a more general way, DTLS v1.3 is very young. Since 2022 we begin to see some implementation of it but not widely widespread.

At Leshan side, we only support DTLS v1.2.

[eabase]

@sbernard31
@rettichschnidi

Hi!
Thanks for the quick feedback and clarification!

At LWM2M level, the specification v1.0 and v1.1 doesn't mention DTLS v1.3.

No, but LwM2M v1.2 is mentioned, while DTLS 1.3 in a maybe context. Seem to say that DTLS 1.2 is fully supported.

DTLS 1.2 is also mentioned here, but that is not well defined weather, and it seem that DTLS 1.3 is optional.

In a more general way, DTLS v1.3 is very young. Since 2022 we begin to see some implementation of it but not widely widespread.

It was released April 2022 (last year). The point being that nothing will ever be widespread before it's actually available! There are basically no FOSS server implementations (AFAIK) that supports DTLS 1.3 today. This at times when IoT development is going exponential.

[boaks]

About DTLS 1.2 vs. DTLS 1.3

One of the main new features of DTLS 1.3, the Connection ID, is backported to DTLS 1.2 via RFC 9146.
Eclipse/Californium supports DTLS 1.2 CID now for two years. Including graceful restart (really nice on server updates!) and CID load-balancing. In tinydtls a client only implementation is available as feature branch. I use that in a small cellular demonstration project no for more than a year with great success. MbedTLS has also recently updated to the final version of RFC 9146.

The left benefits of DTLS 1.3 are then.

• some data saving by a more compact record format (I don't expect that to be a game changer)
• improved security and newer crypto functions. Especially, the IETF seems to move forward only for TLS 1.3 based functions, e.g. "subcerts".

(Maybe @hannestschofenig completes the comparison, he's for sure ways more engaged than I.)

Overall my feeling is, that it's more important to demonstrate the benefits of UDP based protocols, and that could be done with CoAP/DTLS 1.2 CID. We will see, if "enough" products are build on that, so that a development of DTLS 1.3 will be possible in Eclipse/Californium. I don't expect to have time for that in the next 18 months.
Alternatively, mbedTLS comes with DTLS 1.3 and maybe it's therefore a great idea to see, if leshan can make use of that via java-coap not only for coap+tcp.

[sbernard31]

I will answer for Wakaama and for Leshan too. (as you post same kind of comment at eclipse-leshan/leshan#1386 (comment) )

@eabase, It seems to me that you try to convince us as much it's important to move to DTLS 1.3 and LWM2M 1.2.
Don't worry we know that, and if resources are available we will probably go in that direction in the future.

But currently,

Concerning LWM2M 1.2 :

AFAIK, Leshan and Wakaama project are focus on LWM2M v1.1.
I think it makes sense to first focus on LWM2M v1.1 before to jump in LWM2M v1.2. (especially as LWM2M v1.2 more or less includes LWM2M v1.1)
Resources on those projects are limited. Maybe from the outside it seems we move not fast enough. Sorry about that.

Concerning DTLS 1.3 :

Wakaama and Leshan are LWM2M implementation, not DTLS / TLS implementation. So we are also limited by existing FOSS implementation of DTLS 1.3.

For Wakaama, AFAIK, you "should" be able to use any DTLS library. (and so you can try with few library who supports DTLS 1.3 : mbedtls, wolfssl ?)

For Leshan, AFAIK, there is no pure java implementation of DTLS 1.3 (Eventually, this binding https://github.com/open-coap/kotlin-mbedtls. If someone know others, please share 🙏 )
And we will will not implement a DTLS 1.3 library in Leshan.
For now Leshan, strongly depends on Californium /Scandium for DTLS and it does not support DTLS 1.3.
We are working on abstraction to be able to use different implementation than Cf/Sc but doing this abstraction and propose new implementation based on it will take lot of time.

[eabase]

@boaks
@sbernard31

Hi Guys! Again, thanks for quick feedback.

One of the main new features of DTLS 1.3, the Connection ID, is backported to DTLS 1.2 via RFC 9146.
... The left benefits of DTLS 1.3 are then. ...

There are several features in DTLS 1.3 that I believe will be regarded as must-haves in the very near future:

• Substantial power saving when in deep sleep mode, nearly not possible in 1.2
• Substantial security improvements (removing insecure protocols)
• Zero touch provision support.

(And I'm not just saying this from opinion, but we have several large customers who are requesting these very functionalities today.) The future is now. 😉

The effect of lacking support, is that now a bunch of companies are hacking their own versions of LwM2M 1.1++ or 1.2++ in order to support some DTLS features here and there, further confusing and obscuring any standard compliance. These hacks are not FOSS, so detrimental to the community as a whole.

---

To summarize, the differences, in a more clear way:

---

Hope this helps.

_{PS. Now, since April 2022, DTLS 1.3 is not longer a "draft", however, it's stated as "proposal", which I have asked to clarify here:
tlswg/dtls13-spec#282}

[danielinux]

@eabase wrote:

There are basically no FOSS server implementations (AFAIK) that supports DTLS 1.3 today. This at times when IoT
development is going exponential.

Correction: wolfSSL does support DTLS 1.3 since release 5.4.0 (July 11, 2022).
We are still looking for other implementations to set up our interoperability tests.

@boaks wrote:

Alternatively, mbedTLS comes with DTLS 1.3 and maybe it's therefore a great idea to see, if leshan can make use of that
via java-coap not only for coap+tcp.

No, unfortunately there is no support for DTLS 1.3 in mbedTLS yet.

Edit: corrected link (thanks)

[eabase]

@danielinux

Correction: wolfSSL does support DTLS 1.3 since ...

1. wolfSSL (corrected link) - is not a server, just an SSL library.
2. TLS 1.3 is not the same as DTLS 1.3.
3. What FOSS servers do you have in mind that is using wolfSSL?

[danielinux]

1. Apologies, I thought we were talking about server side implementation of DTLS 1.3. wolfSSL supports both sides, and any application can create a DTLS 1.3 listening socket using wolfSSL.

2. I am aware of the difference. I am talking about DTLS 1.3, which as I said is available in wolfSSL since v.5.4.0. AFAIK wolfSSL is still the only C library currently supporting DTLS v1.3

3. Not sure about LwM2M specifically, but a list of FOSS projects with maintained wolfSSL ports is here:
   https://github.com/wolfSSL/osp

[boaks]

If you read the Eclipse Public License V2.0 and some articles about combining that with GPLv2, the main and essential difference is:

• the eclipse open source projects support also the commercial usage without additional license fees.
• GPL is mainly used as dual-license, where you may either open also your extending functions or pay a license fee.

With that, please ensure with other users, that there is really a benefit in supporting GPLv2 stuff.
If so, AFAIK in order to use the EPLv2.0 / GPL dual-license model, it's required to re-license wakaama. That requires the agreement of all contributors (we would need to ask the Eclipse Foundation about the exact process).

There may be an alternative way, where wolfSSL is only one alternative and other alternatives without GPL are also supported, then AFAIK, it doesn't require CQ (process to include external dependencies in order to ensure the "usability according EPL v2.0".)

ARMs mbedTLS comes also with DTLS 1.3 (and DTLS 1.2 CID) and uses a Apache 2.0 license, which fits the EPL v2.0

Just to mention:

DTLS 1.2 Connection ID is implemented in Eclipse/Californium. Eclipse/tinydtls has currently a feature branch support DTLS 1.2 CID as well.

[boaks]

@eabase

(your comment on the 5. March with the table comparing DTLS 1.2 / DTLSS 1.3)

I'm not sure, if you mix up things.
Why should DTLS 1.2 or 1.3 have any influence on the CBOR encoding?

In my experience, the very larges part of the power-saving stuff is the Connection ID (DTLS 1.3, RFC 9147 or DTLS 1.2, RFC 6347+DTLS 1.2 Connection ID, RFC9146), which eliminates the massive usage of handshakes caused by ip-address changes after sleeping. RFC9146 is implemented in Eclipse/Californium and Eclipse/tinydtls (feature branch).

Also in my experience, it's not too unimportant, that an implementation works reliable. For both eclipse DTLS 1.2 Connection ID implementations I have in the meantime very good experience with mid/long term runtime stability.

[julek-wolfssl]

Hi @boaks

ARMs mbedTLS comes also with DTLS 1.3

just to clarify, DTLS 1.3 is not supported in the mbedTLS development branch (https://github.com/Mbed-TLS/mbedtls/blob/development/library/ssl_tls.c#L1305). It is possible that it is being worked on in a fork but mainline mbedTLS does not yet support DTLS 1.3

Juliusz

[boaks]

DTLS 1.3 is not supported in the mbedTLS development branch

Thanks!
(A year ago it was DTLS 1.3 on the roadmap for the near future ).

[hannestschofenig]

I had written a prototype implementation of DTLS 1.3 for Mbed TLS. Unfortunately, the DTLS functionality had to be removed in order to get protype code incorporated into the mainstream Mbed TLS repo. The code was used for the performance measurements in this paper: https://arxiv.org/abs/2011.12035

I have to search where the code is; it shouldn't be too difficult to add the functionality to Mbed TLS again since the functionality of DTLS 1.3 is (intentionally) kept in sync with TLS 1.3.

Needless to say that it would be important to add DTLS 1.3 also to OpenSSL. We have to check their plans.

[hannestschofenig]

FWIW if someone is interested to help writing the DTLS 1.3 functionality, please let me know.

[hannestschofenig]

I forgot to talk about the features of DTLS 1.3.

As Achim mentioned, RFC 9147 brings DTLS inline with the TLS 1.3 developments. The list of new features in TLS 1.3 (compared to 1.2) is long. At a high-level the benefits are: improved security, better performance, and extra privacy protection. DTLS 1.3 adds extra over-the-wire improvements to TLS 1.3 with a new header format.

Achim mentioned that the Connection ID feature was back-ported from DTLS 1.3 to DTLS 1.2. It significantly improves the energy efficiency of DTLS. The DTLS 1.3 CID version offers extra privacy protection.

Going forward I believe DTLS 1.3 is unavoidable since the IETF TLS working group will continue the standardization of new features, which will only be available for (D)TLS 1.3.

Of course, it takes time to implement the protocols and the protocol extensions. WolfSSL has been leading the development of commercial TLS/DTLS stacks. Congrats to their work. I hope others follow soon.

[eabase]

@boaks

I'm not sure, if you mix up things. Why should DTLS 1.2 or 1.3 have any influence on the CBOR encoding?

It could very well be, as the table was produced by collecting the info I could find. In regard to CBOR that is still beyond my technical understanding. Perhaps @hannestschofenig can answer that?

In my experience, the very larges part of the power-saving stuff is the Connection ID, which eliminates the massive usage of handshakes caused by ip-address changes after sleeping.

This is really a collection of items that all help to reduce handshake and data transfers. Only a real world test with functioning libraries can give specific number of this reduction, but from spec's it seem pretty clear it should be more than significant, for sleeping devices with regular wakeups, that also require the highest reliability/connectivity.

Also in my experience, it's not too unimportant, that an implementation works reliable.

That's a double negation.... :)

[boaks]

CBOR

It is the encoding of the coap-payload. It's something as "binary JSON". But as I wrote, I can't see
a relation to DTLS 1.2/1.3.

This is really a collection of items that all help to reduce handshake and data transfers.

As I wrote, if you start to sort the things in DTLS 1.3 / DTLS 1.2 related and others (as CBOR), you will see, that pretty much of the benefits from DTLS 1.3 already comes with DTLS 1.2 CID.

Only a real world test with functioning libraries can give specific number of this reduction, but from spec's it seem pretty clear it should be more than significant, for sleeping devices with regular wakeups, that also require the highest

Exactly, therefore I created zephyr - coaps-client, which demonstrates CoAP/DTLS 1.2 CID using a LTE-M/NB-IoT modem. A longterm test autumn 2022 showed the efficiency and pretty well reliability. That reliability has been improved since that, but 120 days wasn't that bad.

So, those who like to have a look on what is available may check out DTLS 1.2 CID.
And others may either wait or engage themself.

[eabase]

@boaks

[CBOR] I can't see a relation to DTLS 1.2/1.3.

You are right. Sorry for the confusion.

The table I showed was originally based on a LwM2M comparison. So CBOR is not related to DTLS in this context. What is related is that LwM2M >= v1.2 does use LwM2M CBOR, whereas previous versions do not, which indirectly means that any LwM2M with DTLS support >= 1.2, also has LwM2M CBOR. So ignore feature 7 in the table.