Missing (D)TLS IoT oriented features in Java world ?

[sbernard31]

I'm the main maintainer of Leshan project : a Java LwM2M implementation hosted by Eclipse Foundation.

Until now we are using Scandium (a java DTLS 1.2 implementation hosted Eclipse foundation from Californium project) but recently I need to look at TLS 1.2 for Leshan (because we try to add coaps+tcp support) and I came to the conclusion that :

There is not so good choice in Java world for DTLS and TLS for IoT.

I ask myself if my assumption :

• is wrong ? and so I maybe missed something.
• OR is right ? and so we are probably several to face this situation and maybe we can collectively try to improve it.

I created a github repository and begin to summarize some information about that : https://github.com/sbernard31/thermos

The idea would be to :

• Make a good big picture of the situation,
• Collect needs from IoT Java Community,
• Report our need to existing (D)TLS implementation, (to maybe impact their TODO list)
• Find collective solution ?

I try to talk about that at security-dev mailing list from OpenJDK and this is not clear if they will work to improve that situation, here is a link to that discussion : https://mail.openjdk.org/pipermail/security-dev/2024-March/038906.html

After speaking with Frederic Desbiens, he advises me to contact Hono project as it could be interested ? If you are, do not hesitate to discuss with us at https://github.com/sbernard31/thermos.

[sophokles73]

I am not sure if I understand correctly. Do you want to improve the existing DTLS implementation in OpenJDK?

[sbernard31]

Uups, bad point for me it will be hard to involve people if I'm not clear. I should consider to review my text to improve this.

So try to summarize better.

My understanding :

• IoT use cases need some DTLS and TLS features.
• This feature are rarely implemented in Java world. (not an OpenJDK problem only)

This sounds a problem for Leshan project but I tell myself this could be a general problem for others Java IoT project.

So I create this project to (collectively?) :

• Make a good big picture of the situation, (List IoT feature and which libraries implements what)
• Collect needs from IoT Java Community, (List most needed feature from IoT)
• Report our need to existing (D)TLS implementation, (Hoping we can impact their TODO list)
• Find collective solution ? (this is unclear for now but could looks like Discuss about possible solutions sbernard31/thermos#3)

Do you want to improve the existing DTLS implementation in OpenJDK?

This could be a way (lobbying to change OpenJDK TODO list and/OR try to help pushing code). But maybe not the only one possible solution, we could also imagine to try to add needed API in OpenJDK and push implementation in BouncyCastle.
OR maybe work on a durable project which host an mbedTLS java binding?

I don't know exactly 🤷
But first we must be sure that IoT Java Developers agree about the situation and collects their needs then later see how we can solve it.

(Note that I'm not just talking about DTLS but also TLS in version 1.2 and/or 1.3)

Do not hesitate to ask again if still not clear 🙂

[sbernard31]

@sophokles73 maybe my approach was not so good.

So let's retry differently.

Can I ask what are you using as library for DTLS or TLS ?
Which version of (D)TLS are you using ?
Are there some (D)TLS feature not implemented in current implementation you would like to use? If yes, could you list it please ?

[sophokles73]

Hi @sbernard31,

thanks for coming back with this.

Can I ask what are you using as library for DTLS or TLS ?

Hono's CoAP Adapter uses Scandium for DTLS as part of Eclipse Californium, on which the adapter is built. This results in DTLS 1.2 being used.

The other adapters use the JVM's default TLS implementation but can also be configured to use boringssl. By default, the adapters are configured to use TLS 1.3 and 1.2, but they can also be explicitly configured with TLS versions and ciphers to use.

Are there some (D)TLS feature not implemented in current implementation you would like to use? If yes, could you list it please?

For DTLS we are good, I guess. For TLS it would be cool to be able to have some (async) callbacks available to plug into the TLS handshake for e.g. verifying keys in PSK based ciphers programmatically.

[sbernard31]

Thx @sophokles73 for your answer. 🙏

The other adapters use the JVM's default TLS implementation

OpenJDK are lot of missing common (D)TLS Iot feature, see : https://github.com/sbernard31/thermos/wiki/Existing-(D)TLS-implementations-for-Java#does-it-supports-critical-iot-features

On our side, this is an issue.

Just to be sure none of them is wanted for you ?

can also be configured to use boringssl.

Which binding are you using Concrypt or maybe netty-tcnative ?

Do you face any particular issue about using native binding instead of pure java ?

Hono's CoAP Adapter uses Scandium for DTLS as part of Eclipse Californium, on which the adapter is built. This results in DTLS 1.2 being used.

Ok as you know we also use it for Leshan. It works well and is a good choice for present.
But we have some concern about its "futureproofness", (some reason here) and so we would like to anticipate and look for futureproof alternative.

Do you also have this kind of concerns ? How do you see future about that ?

[sophokles73]

Just to be sure none of them is wanted for you ?

At least we are currently not missing any.

Which binding are you using Concrypt or maybe netty-tcnative ?

netty-tcnative

Do you face any particular issue about using native binding instead of pure java ?

The only thing that requires some effort is figuring out which jars need to be included in the class path.

Do you also have this kind of concerns ? How do you see future about that ?

I share your concern but currently, Hono is just a private project for me, so this is a question for our commercial adopters. @StFS any thoughts on this?

[StFS]

I'm afraid that I (or we) don't have the capacity to dive deep enough into these types of technicalities for them to have become a concern for us no.

The only thing we've experienced some issues with is supporting the DTLS ConnectionID extension, but that's more of a Hono issue rather than an issue with Scandium. We started some experiments to add this support to Hono but that work is on hold for now. Initial findings seemed to indicate that Scandium supported it but the main unanswered question for us was one that I see in the checklist @sbernard31 linked to, namely, whether Scandium properly supports a central session store so the devices won't need to re-negotiate DTLS if subsequent requests get handled by different adapter instances. To be clear, we just haven't had the capacity to look into it properly, it may very well be fully supported and possible to do.

Other than the above, we haven't found any shortcomings regarding the DTLS implementation that cause us much concerns up until now. The fact that you mention here though, that the Scandium project is not very actively maintained is of course not great.

That's unfortunately all the info I can provide from our side about this.

[sbernard31]

Thx guys for taking time to answer 🙏