Interest in DTLS 1.3 support?

I think that there is wider interest in having DTLS 1.3. It's been asked for as a feature a number of times.

Targeting 4.0 seems reasonable, although this requires someone willing and able to do the required work & reviewers who feel confident reviewing the code submissions.

I'm not one of those able to do the required work so I might be completely mad suggesting this.

I agree (with all statements, unfortunately). This begs the question, then, how do we get word out to find more people interested in contributing to that feature branch to move it forward? This "General" discussion "group" seems to be one limited to 16 people.... Created https://openssl-communities.org/d/eMUxfhPC/a-really-general-discussion-forum to propose a change to that...

Yes, DTLS is widely used in IoT and embedded systems. But sometimes OpenSSL is not very optimized for that kind of cases (in the aspect of binary size and memory usage). So it's kind of a bit paradoxical.

IoT devices generally talk to a back end server which has the space.

So what (D)TLS stack(s) are these servers using? Is there (commercial? community?) interest to replace those with OpenSSL?

The option I know of is WolfSSL which is optimized for embedded systems. They have an OpenSSL compat layer. So switching between the two implementations could be seamless but I haven’t tried it.

Mbedtls (to my knowledge) does not have DTLS 1.3.

WolfSSL is one option

From the bits I've looked at, Wolf's compatibility layer includes a lot of functions that just return 0 or NULL for failure. It's a lot better than nothing and is good to avoid linking errors but it's not ideal.

So what (D)TLS stack(s) are these servers using? Is there (commercial? community?) interest to replace those with OpenSSL?

Many would already be running OpenSSL and are unable to use DTLS 1.3 even though they'd like to.

We (the Foundation) received funding to progress the work on DTLS-1.3 support. It is not enough to fund the whole implementation effort but at least it will allow us to do the reviews and some other auxiliary work that is needed to get the DTLS-1.3 support implemented.

That's excellent news closing an important gap (timely and thorough reviews). Thanks for sharing this information @Tomas Mraz !

@Tomas Mraz If the fund is kind of limited and as per we have the consensus that OpenSSL would be more used at server side, then how about the Foundation start from the DTLS-server stuff?

@Paul Yang I don't really think this will make the work smaller and we need both sides for testing.

As mentioned in the GitHub issue thread: my company is interested in the feature to enable pqc for encrypted voice and video calls.

I can contribute code and reviews. But it will be in my free time.

I know Cisco is interested in having this feature. I am willing to help in this area the best that I can.

DTLS 1.3 is the only way to have PQC in DTLS, so I'd say it is quite important...

This is true -- but then begs the question: How much usage of DTLS (via OpenSSL) is there already? Could we try to convince that (DTLS 1.2) community to contribute more to 1.3 (and if only to close the PQC gap there)? Does anyone know of "heavy OpenSSL DTLS (1.2)" users?

+1 for DTLS 1.3 as an important feature if only for PQC availability

Thanks everyone for their statements of interest -- particularly for possible contributions! (Hopefully :) last question from my side: Is the (pretty long) discussion in GH (https://github.com/openssl/openssl/issues/13900 sufficiently well-structured to allow interested contributors to pick up tasks or should there be more "bite sized" tasks, e.g., separate issues? Would there be interest for a kind-of "birds of a feather" session at the OpenSSL conference around how to speed up DTLS development?

A session would be a great place to start. And we could post a summary to the GitHub issue to distribute the knowledge to a wider audience.

@Hana Andersen I know you have too much to do already these days, but allow me to bring the above to your attention anyway with the question whether this can still be facilitated somehow? Alternatively the question to @Jon Ericson : Would you be willing to at least "pick up" this topic somehow in your "community talks" at the conference such as to somehow physically bring together people interested in this topic also attending the conference? Even a quick informal personal get-together might do a lot to move this forward.

@baentsch I don't know if there is a formal way to do this at the conference, but I will ask around to see if we can make something happen.

I've booked the London room (using https://openssl-conference.org/meetingrooms/reservation/) for today at 12 to 1 pm. I also sent out an invite to the people I believe are at the conference. Please add other people to the invite if I missed anyone.

If the time doesn't work for you (it is designated for lunch) please suggest another time on the invite. Scheduling is always awkward, but at least this time we don't need to worry about timezones!

I updated the invite for tomorrow at noon. Sorry for the late notice this morning.

Turns out the meeting happened and there will be a writeup soon.

Thanks @Jon Ericson for sending the invite around. Thanks @Frederik Wedel-Heinen @Ryan Hooper @Jeff Johnson for coming to the meeting.

My take: This feature is very much desired by Cisco and the whole team (Ryan in the lead) is very much motivated to put in work to fix the remaining issues by adding tests and required code to get this "across the finishing line". Frederik stated his personal change of priorities to other things but confirmed his willingness to still serve as reviewer (and possible "code guide" if needed) for anything Ryan does. I'm myself willing to help with anything around PQC (although assuming things should work smoothly as testing had been done earlier using oqsprovider). Jeff stated management support by Cisco to move this forward.

This, together with @Tomas Mraz statement above to help with reviews as and when PRs become available to me seems like there is a plan and commitment to move forward. It would be nice if someone now could post/agree a timeline (deadline) by which this work should be completed to give this the "final push" and urgency. @Matt Caswell : Would you think 4.0 is a realistic goal and would you support (Ryan working for the Foundation on) that?

PS: Anyone violently disagreeing with this summary, please speak up and correct me (and/or hit me over the head while we're all in the same place :-)

@Michael Baentsch I think 4.0 is possible goal, although that will require a concerted effort. However at worst this will be finished for 4.1.

4.0 seems like a very reasonable objective.

I did a summary of the DTLS feature branch status on the issue page:
https://github.com/openssl/openssl/issues/13900#issuecomment-3400806024

@Ryan Hooper Please let me know if you need a teams meeting to resolve the questions you might have. And please do ping me for reviews.

@Frederik Wedel-Heinen Thanks for the summary.