You're not wrong, but I think the point was, in a browser, you can get your TCP _connection_ "automatically" encrypted by connecting to HTTPS endpoints. It's not so easy -- "built in" -- with a connectionless protocol.

That's entirely true and it's one reason why I hesitated before nitpicking. That said, I think that the distinction should be properly made when someone is discussing a new way to sling data over a network from the application layer. If the author had written what you'd written, I'd have let my reply go.

(Even so, it's not that the "TCP session" is encrypted; it's that the transport-layer security mechanism encrypts the payload of the TCP session. The metadata for the session--the respective IP addresses, sequence/acknowledgement numbers, and so on--is still in the clear. I realize that, at this point, I'm being quite pedantic but I'm a networking person at heart and I want software developers to better understand the infrastructure that's being used.)

i think its fair what you said. webrtc offers "automatically" encrypted UDP if we are comparing like that.

But we already knew that. It's in the article, so again there is a story here that you're missing. We want a client/server protocol that is encrypted and simple -- not requiring ICE/STUN/TURN (OMG).

If you already have Websockets, then Simple-Peer makes it very easy to deal with WebRTC negotiation. As I've mentioned elsewhere, I've created a 4 process WebRTC UDP proxy with that running under nodejs. My use case is precisely client-server.

There is DTLS if you really want turnkey encryption for UDP, and it's implemented by openssl so it's straightforward enough to find an implementation. Not the most widely deployed protocol out there, to be sure, but if browsers wanted to make that the condition of use it would soon become widely implemented.

"openssl [...] straightforward" I don't think so. It's in the article; DTLS is too complex. The author wants something simple.

Most implementations (eg. WebRTC) involve pulling in truck loads of C libs; it's insane. And then you want to support other clients? Good luck.

Not quite turnkey, but openvpn is essentially tls over udp with an ip tunnel on top

I have implemented TLS on UDP. Basically to implement an EAP-TTLS authentication service which sets up a TLS tunnel over EAP over RADIUS over UDP. I can attest that is "doable" but is horrendously complicated. Not just to implement but to monitor and debug.

It "works" in the case of EAP because you're never sending more than a few datagrams at a time, and if one gets lost it's not a huge tragedy to have to start the whole process again ... but, I can't imagine this being feasible for more continuous data-transfers such as streaming data "oops you lost a packet - sorry you'll have to re-establish your TLS session again"

I did notice the DTLS thing lying around when I was browsing the OpenSSL source but as another commenter says it's not that popular and presumably suffers many of the same complications.

Is there a reason you couldn't use TCP/TLS to establish a shared secret, and then just encrypt all your packets with that?

Gosh .. I eh .. I guess I was just given this RFC to implement [0] I'm not sure of the reasoning specifically for doing it this way.

But kind of related to your point, TTLS does in fact use the "cryptographic material" derived as part of session establishment to derive a shared secret for hashing in CHAP, MS-CHAP and MS-CHAP-v2! [1] The nifty thing about that is it "binds" the ensuing authentication process to the actual TLS session. With MS-CHAP-v2 it also provides for mutual authentication without either party ever having to exchange sensitive info (neither client nor server ever has to know the password).

This was actually a real pain to do with Open SSL as that information wasn't readily available with the standard API. I had to implement some horrific cludge to get the necessary info nested within 3 layers of structs.

[0] https://tools.ietf.org/html/rfc5281

[1] https://tools.ietf.org/html/rfc5281#section-8

DTLS is a foundation of CoAP protocol (request/response) for the IoT world [1]

I personally think, it will see wider usage in upcoming decade.. but it is just a guess.

[1] https://projects.eclipse.org/projects/iot.tinydtls

Gosh I hope so! The current melee of devices chatting away without any security is a big cause for concern.

DTLS is also the foundation of webrtc, which is talked about in this topic a lot and which is implemented in most browsers now. This means DTLS is important - but unfortunately not offered by lots of libraries (e.g. not by the Go network/crypto libraries)

This is also true of IPSec AH and ESP. You can use it purely for labeling (turn off both)

IPsec, not IPSec

It's been 10 years since I worked on a VPN stack, but naming pedantry dies hard.

Actually the encryption question is interesting, you couldn't use modes like CBC in out of order. What technique would be used for out of order decryption?

Pick your mode, separate IV per record, separate record per packet.

> UDP packets are not encrypted

how does QUIC do encryption?

QUIC Crypto design doc:

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...