DTLS support for UDP client

[SunnyWar]

dotnet/corefx#29711 (moved to https://github.com/dotnet/runtime/issues/26173) was closed without resolving the issue. Re-opening it here. We need DTLS in .Net.

As @sipsorcery pointed out, DTLS is needed for the implementation of WebRTC. Also, there does not appear to be any progress on QUIC protocol that @karelz pointed out. In any case, it's not available, so it's not a workaround.

If the powers that be choose to close this again, please show tracking on QUIC or an open-source workaround. Closing without this information is rude.

[scalablecory]

We need DTLS in .Net.

Can you give some specific scenarios you're looking to enable?

As @karelz noted in https://github.com/dotnet/corefx/issues/29711 (moved to https://github.com/dotnet/runtime/issues/26173), we currently have no plans to add DTLS. Having some killer scenarios might provide some motivation.

there does not appear to be any progress on QUIC protocol

There has been progress on QUIC. https://github.com/dotnet/runtime/pull/427

[SunnyWar]

@scalablecory for the additional information. The scenario that I'm familiar with is audio/video streaming. Without DTLS one is left with TCP, which imposes higher latency and bandwidth requirements. If you look at all the major VOIP applications on the market, they use UPD for the audio streams...and they don't use .Net and probably won't desire to switch to it because...no DTLS.

[karelz]

WebRTC was mentioned on that thread even earlier. Overall we are still not convinced that there is need to have this protocol in the platform itself. QUIC is on its way to cover some of the needs (see PRs in the repo as @scalablecory linked them), though it will likely not land in .NET 5. To track some of the progress, you can see opened QUIC issues like #1533 or overall GH project for HTTP/3

For specific DTLS protocol implementation, there is a community project mentioned in the previous bug - https://github.com/CreatorDev/DTLS.Net

To change our minds on DTLS, we would need either killer scenarios or much more interest from partners and community with good reasons why the 2 alternatives are not sufficient.

Closing to express our intent to not take contributions with DTLS into .NET platform itself.

[karelz]

@SunnyWar how many VOIP apps are there? Is any one of them seriously investigating option to use .NET? Why is the DTLS project linked above not sufficient?

In general, VOIP seems to be fairly specific segment to me. I would like to see more general usages to make the case for having the protocol in the platform vs. just built-on nuget package.

[SunnyWar]

@karelz You wanted and an example, I gave you one. Making it sound like it's the only one is an odd response. Try to broaden your view. I recently finished a project that involved TLS mutual auth, client-to-client communication. Some of the data were to be in transmitted TCP and some on UDP. Once I discovered that .Net did not support DTLS, I had a number of uncomfortable options: 1) write the whole thing in another language (My co-worker wanted this option), 2) Write the auth/communication layer in and interop between .Net and C (this is the option I chose) 3) try to find a third party solution that can be FIPS certified (I could not find any).

[karelz]

@SunnyWar let's try to de-escalate the chat here, let's be technical, without accusations of rudeness, not enough broaden views, etc. ...

You gave us example of VOIP (thank you for that), which is fairly limited scenario as I tried to explain: The problem is that for almost anything in the world, one can find a scenario. The key question is, how common is the scenario and how many customers need it. Is 1 customer enough? (maybe a government) What about 10 customers? (maybe VOIP providers) Or 100? Or thousands / millions? Based on my experience, in platforms like .NET, thousands and more start to be interesting numbers. And even that is sometimes not enough. And sometimes 100 may be sufficient -- depending on who the customers are, how blocking scenario it is (are there workarounds), impact, etc. etc.

Sorry to hear that you considered my response odd. I hope it was just misunderstanding / misinterpretation of my reply (which is easy to do in "just" written form, when emotions are lost from communication). To clarify: Our position is based on the data we have (mainly from the 2 issues) -- popularity/demand for the protocol (about 8 people + VOIP scenarios), workarounds availability and costs (incl. maintenance). That data does not come favorable at this moment for DTLS -- to the point, that we would even NOT take a PR with "perfect" implementation into .NET Core. We would rather ask that code to stay outside of .NET platform as an independent library built on top of it (like the existing project does). Note: We did similar thing to many other API surfaces (incl. specialized/advanced collections) Obviously, our position can change over time if we find new evidence that would change inputs into this equation -- like more scenarios, signs of more importance for scenarios, etc. etc.

As you probably understand, we cannot have everything implemented in .NET, we have to prioritize and choose which features and/or protocols we include in the platform. And because everything has a cost, even OSS contributions (aka "free of cost code") are sometimes rejected, because they bring long-term cost of maintenance and complexity which may not be worth the benefit. As you mentioned and as was mentioned in the original thread, there is existing community project. It is not uncommon for corner-case scenario features to be pulled out into separate nuget packages and be maintained by the very audience that needs them.

DTLS falls into this category -- the value is limited (based on our current knowledge) - the protocol is not very popular, it is used in scarce places/scenarios, and there are existing workarounds (external package + alternative under-construction protocol QUIC).

On a side note: AFAIK .NET Core is not FIPS certified, so having DTLS implemented as part of the platform would not help with your point above [3] where you were looking for FIPS certified 3rd party solution.

If you think I missed some important points, or if there is more information available that was not mentioned yet, please let me know.

[sipsorcery]

The VoIP angle is a bit of a red herring as far as DTLS is concerned. It's only required when the media (RTP) channel needs to be secured (SRTP).

As to whether including a particular foundation protocol in dotnet would be worth it as far as uptake by application developers it's a chicken and egg situation. We can't really know. Anecdotally there are some pretty powerful communications apps (Slack, Skype etc.) that would lend themselves well to Windows and .Net/dotnet. Without the fundamental real-time communication protocols the hurdles are too high for most app developers to consider dotnet.

But back to the main case for DTLS. WebRTC is supposedly the next big thing for web apps and Microsoft has been a big supporter of it including Microsoft employees on the WebRTC standards committees. Personally I think integrating DTLS into dotnet would be a small investment for a medium return. It's not a big stretch from TLS to DTLS so the effort is likely less than anticipated. As the popularity of WebRTC increases app developers will be looking for a way to provide real-time communication experiences in the current way they currently provide web experiences.

I've tested a number of the open source DTLS libraries for dotnet, including the one mentioned above, and have had no success talking integrating with popular DTLS servers or a WebRTC client. The solution that does work is to go down the C++ path and use OpenSSL. The learning curve to do that is 10x compared to the comfortable consistency of the dotnet base class library.

[karelz]

Looking at WebRTC on wikipedia - that seems to be targeting mainly VOIP endpoints in browsers. Is that correct? Also, is it built on DTLS? I didn't find any mention of that on wikipedia ... (sorry, didn't have time to dig into RFCs)

Why do you think the investment is small? What does small mean in this context? 1 month, 2 months, more? What is the medium return -- anything beyond VOIP-class apps?

[sipsorcery]

VoIP typically means Voice over IP and in that respect WebRTC is a lot more. As well as audio it also has video, data channels, hooks for accessing local video/audio devices and more. It's also a replacement for the Flash plugin and all its security woes.

In the WebRTC Architecture stack DTLS is the mechanism use to negotiate the symmetric encryption key for SRTP which in turn encrypts the audio/video packets on the wire. DTLS is effectively the same thing as TLS but for UDP instead of TCP. DTLS does the Diffie-Hellman key exchange to set up the AES encryption key for the RTP media packets. The top level chromium DTLS classes can be seen here.

Why do you think the investment is small? What does small mean in this context? 1 month, 2 months, more?

For somebody that worked on the System.Net.Security.SslStream I would think an alpha version would take a month or perhaps two. It's all the same crypto primitives, certificate management etc, The task is adjusting to cope with UDP transmission instead of TCP.

What is the medium return -- anything beyond VOIP-class apps?

Another popular use case is Internet of Things (IoT) apps. A lot of times these devices prefer UDP instead of TCP to save resources (takes more battery to maintain TCP state compared to UDP). The problem is how can UDP transmissions be secured? Without something like DTLS it will require the app developer to roll their own hence the numerous IoT device exploits.

[karelz]

Thanks for answers, few more questions:

I don't see DTLS mentioned in the WebRTC Architecture doc ... am I missing something?

For somebody that worked on the System.Net.Security.SslStream I would think an alpha version would take a month or perhaps two. It's all the same crypto primitives, certificate management etc, The task is adjusting to cope with UDP transmission instead of TCP.

The TLS protocol is taken care of by external layer - OpenSSL (Linux/Mac) and Schannel (Windows). We do not deal with that part. I am curious who handles the congestion management, packet loss, etc. in that case (unless it is magically handled by the underlying libraries). That will be IMO the tricky part.

IoT apps

I would expect that these scenarios could leverage QUIC implementations instead of DTLS going forward. For general UDP+TLS solution.

BTW: It seems there may be some thoughts on QUIC + WebRTC as well: https://bloggeek.me/who-needs-quic-in-webrtc/

[sipsorcery]

I don't see DTLS mentioned in the WebRTC Architecture doc ... am I missing something?

Yes they've left it out. I suspect under the assumption it's an assumed part of the SRTP block. Coincidentally it is shown on the QUIC blog post you linked, halfway down in the "High Performance Browser Stack".

I would expect that these scenarios could leverage QUIC implementations instead of DTLS going forward. For general UDP+TLS solution.

That's going to be a long way away (year(s) at best). There are bound to be IoT devices in the field that never get QUIC.

Still I appreciate the point, resources are always limited. If DTLS/SRTP don't make it in to dotnet maybe the next batch of programmers will have QUIC & HTTP3.

[sipsorcery]

Appreciate it's flogging a dead horse at this stage but while doing some WebRTC testing with Microsoft Edge came across RTCDtlsTransport and ORTC API. So suffice to say there is already a DTLS stack somewhere in Microsoft.

[sipsorcery]

@SunnyWar if you're still looking for this someone else pointed out a DTLS implementation for .Net Core buried down in the BouncyCastle project.