Runtime: DTLS support for UDP client

[l0nley]

Hi!
I am looking for DTLS implementation for .NET.
It looks like this is not supported yet? Do you have any plans to support it?

[karelz]

Currently we do not have plans to add DTLS support.

There are some community projects though: https://github.com/CreatorDev/DTLS.Net

[l0nley]

Its very sad to hear. I can imagine many appliances, such as IoT. I am aware about community projects, but as you can see project you suggested not maintained for 2 years, as well as it has tons of limitations, like "No support for fragmentation of handshake packets" which limits its usability.

[davidfowl]

How widespread is DTLS I haven't seen it used anywhere...

[l0nley]

Well, DTLS is implemented by several projects including Cisco AnyConnect, F5 Networks Edge VPN Client, Citrix Systems NetScaler, OpenSSL, and actually web browsers support DTLS-SRTP for WebRTC.

[SunnyWar]

Add me as someone that wants this. I'm working on a project right now that will take _significantly_ longer to complete without it.

[davidfowl]

Do other platforms have DTLS built in or are they all 3rd party packages? I can't see this getting prioritized over other networking work tbh. We still need to implement HTTP/2 and QUIC and HTTP/3... Not to mention the other issues and general improvements for the existing networking stack.

[l0nley]

What do you mean under other platforms? And, just in case these "platforms" do not have build-in support of DTLS, does it mean .NET should not have this feature?

[davidfowl]

Other platforms - java, golang, python, etc.

It’s a data point, we don’t just do features because issues are filed. There’s are thousands of issues and feature requests and this one in particular doesn’t bubble to the top. As I said before, AFAIK, I’ve rarely seen DTLS requested and there are 3rd party libraries that have this functionality. I’m not convicned this needs to be in the BCL.

[l0nley]

I am little bit confused by your answer. I am actually trying to use .NET for networking-things. And networking not always HTTP(S). Microsoft did great steps towards usage of .NET everywhere (like adding Span types, Value tasks, cpu intrinsics, etc). I am not sure, that I can provide solid answer, whether go, java, or whatever-language-i-do-not-know support particular feature or not. And actually I am not sure, I should _convince_ you to do something. But straightforward googling tells me that at least there are proposal https://openjdk.java.net/jeps/219 and somehow https://openjdk.java.net/projects/jdk9/ includes it.
And... I am really confused by something like "If other platforms do not have it - .NET should not have it". It makes impression, .NET will be man, who always behind the leaders.

[karelz]

As @davidfowl said, it is one of the data points. It is not wide statement we only follow others.

Regarding this specific ask, given the (low) number of upvotes, the complexity of such feature, the fact there is existing community project and the fact that we have much higher priority gaps in our networking story (HTTP/2, QUICK, HTTP/3, other high-impctful issues in networking filed in this repo), it is highly unlikely we will get to this in next couple of years (just setting realistic expectations).
I am fine keeping it open to solicit more feedback and upvotes over time.

[karelz]

Triage: We believe that QUIC protocol (which we are looking into) will supersede DTLS protocol. We may have some APIs exposed for QUIC too, which will fullfill this ask.
Closing as it is not needed to be tracked separately.

[SunnyWar]

@karelz perhaps include a reference the item related to QUIC so that we can track its progress?

[sipsorcery]

Perhaps the reason at least some of us are asking for DTLS is because it's required for WebRTC which has gained a lot of momentum. QUIC is highly unlikely to replace DTLS for WebRTC anytime soon (if ever).

There also seem to already be a few DTLS implementations in Microsoft products perhaps one of those could be leveraged for dotnet.