DTLS1.3 support

[eliot4321]

Hi,

Does Californium support DTLS1.3? if not, is it expected to be supported any time soon?

Thanks in advance.

[boaks]

It is neither supported nor planed in the next months.

Though Californium is an open source project, contributions are very welcome.

Californium supports DTLS 1.2 Connection ID. Using java 11 runitme, x25519 is added for ECDHE. If I get the time to do so, I would also try to implement ECDSA based on that curve and maybe TLS_???_CHACHA20_POLY1305_SHA256. But that depends on the time I'm able to spend into that.

[boaks]

I don't expect contribution for DTLS 1.3 "soon".

[sbernard31]

@boaks, is this still not planed at short/mid term ?

[boaks]

At least from my side not in short.

I consider, that using DTLS CID will provide already many benefits. With mbedTLS and tinyDtls there are already two client implementations, and at least my Thingy:91 runs not that bad with it.

I currently think more about implement RFC 7924 - certificate caching, but that depends more on some decision out side of my responsibility.

The amount of work for DTLS 1.3 is large. And AFAIK, only mbedTLS seems to offer that in short. Do you have any specific feature of DTLS 1.3 you consider to be high lighted? Faster handshakes seems for me not that important with DTLS CID (and cert. caching).

[boaks]

Maybe, I check, if bc has some functionality to use for short term.

[boaks]

Should I open this issue again? But from my experience, either I do it, or "nobody ;-)".

[sbernard31]

The amount of work for DTLS 1.3 is large

I guess it.

And AFAIK, only mbedTLS seems to offer that in short.

AFIAK there is not so much DTLS 1.3 implementation. I also see that the RFC-dtls13 is still a draft.

Do you have any specific feature of DTLS 1.3 you consider to be high lighted?

Not really but we begin to detect some interest about (D)TLS 1.3 in general. And so I just try to get some news from you about this.

Should I open this issue again?

This is up to you.

Thx for all those information. Let me know if (D)TLS 1.3 becomes a mid / short term subject for you.

[boaks]

AFIAK there is not so much DTLS 1.3 implementation. I also see that the RFC-dtls13 is still a draft.

The RFC9147 is in the editors queue (as RFC9146 also), and mbedtls plans to support in in the near future.

Not really but we begin to detect some interest about (D)TLS 1.3 in general.

Yep, but at least my feeling is, this is more for general interest than for a specific feature.

Let me know if (D)TLS 1.3 becomes a mid / short term subject for you.

Once I start with it, I will let you know.

[eabase]

@boaks @sbernard31

I also see that the RFC-dtls13 is still a draft.

The RFC9147 is in the editors queue (as RFC9146 also) ...

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:

https://github.com/tlswg/dtls13-spec/issues/282

this is more for general interest than for a specific feature.

Not anymore. People want 1.3 because of (at least) 3 main reasons:

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

[boaks]

Substantial power saving when in deep sleep mode, nearly not possible in 1.2

DTLS 1.2 Connection ID is exactly what's needed for that. I developed zephyr-coaps-client with Eclipse/tinydtls. With that a Thingy:91 runs from the internal battery over more than 6 months exchanging every hour a message. DTLS 1.3 will not really improve that further.

Substantial security improvements (removing insecure protocols)

Just configure the client and servers stack not to permit such "insecure protocols". Or at least to prefer the secure ones.

Zero touch provision support.

I'm not familiar with that.

DTLS 1.3 is for sure a good development. Unfortunately the industry have lost the interest to finance such developments. For Californium itself it's hard to make decision to add implementations, e.g. DTLS 1.3 and to keep the quality. It's a question of the trade-off. For sure there will be different opinions on that. On my view, it was mainly me who did the debugging and bug-fixing for the past 5 years and I'm not longer able to spend that huge amount of time doing so.

Therefore my focus is on using CoAP/DTLS 1.2 Connection ID and demonstrate, how products benefit from that. Let's see, if that brings back the interest.

[eabase]

Hi Achim, Yes, thanks for clarifying and updating.

Zero touch provision support. ... I'm not familiar with that.

It's basically the same as One-step device commissioning, but cloud based. You put the SIM card in the device and power it on, and it works after you have registered the device IMEI with your IoT management provider.

[redoriental]

The current quic protocol seems to require dtls 1.3

[boaks]

AFAIK, I may be wrong, QUIC RFC 9100 comes with it's own security.

[redoriental]

Do you know "webtransport" is a transport tool on this browser. It is similar to "websocket" based on udp, and it is based on dtls 1.3 for the quic protocol

[boaks]

No, I don't know "webtransport".

[redoriental]

Well, my hopes of creating an http3 server have been dashed

[boaks]

Well, my hopes of creating an http3 server have been dashed

Now I understand, you want DTLS 1.3 for HTTP3 . As I wrote, I think QUIC comes anyway with it's own security.

The point with DTLS 1.3 and Californium is simple, I tried to explain it above. For a "hobby contribution" a DTLS 1.3 implementation will be quite time consuming. And a "professional contribution" hasn't shown up for a couple of years. With that, I'm happy to use a stable and mature DTLS 1.2 CID implementation.

[redoriental]

thank you，I know the meaning that you say

[yangyangliuli]

Hi boaks， Your answer is so interesting，but now I still have two questions: 1)Does californium support coap+DTLS1.2+session resumption now? If supported, how to start the server? 2)Does californium support coap+DTLS1.3 now? As far as I know, only wolfssl supports DTLS1.3 now. Do you know that mbedtls supports it now? Does californium have plans to add DTLS 1.3?

[boaks]

1) Yes. It is enabled by default, see DTLS_SERVER_USE_SESSION_ID.

2) No. For mbedTLS it was announced some time ago, but the last time I asked, I got the answer, that I'm welcome to implement it.

Plans: I'm not longer payed to work in open source. Therefore it's now a hobby project. My personal plan is to spend something as 4h (one afternoon) a week for Californium and tinydtls together. I don't think, that starting to implement DTLS 1.3 makes sense with that. Out of that scope of that 4h I implement my idea of an CoAP-S3-Proxy and improve my cellular demo client. With that, investing my own time in DTLS 1.3 doesn't make too much sense.

[yangyangliuli]

Ok, got it, thank you for your answer.

[boaks]

You're welcome. Just to mention, because you ask about "session resumption", Californium supports RFC 9146, DTLS 1.2 Connection ID, which usually obsoletes session resumptions caused by ip-address changes.

[yangyangliuli]

Thanks for reminding me, my colleague has already encountered this problem.

[boaks]

Pretty long without any interest to contribute such an implementation. Therefore I prefer to put it in hibernate. If someone wants to work on this, don't hesitate to leave a comment here.