2

We are exploring options on encrypting messages to 3rd party devices which operate on UDP messages.

Since each vendor will need to implement the encryption-decryption process as well, we would like to re-use the existing standards as much as possible.

But DTLS is considered a no-go because we are using Java, and DTLS only came to Java in version 9 (which is also a no-go). Apart from that, it has several issues which I believe can causes latency.

Apart from DTLS, what other options exist for UDP message encryption?

schroeder
  • 123,438
  • 55
  • 284
  • 319
emaayan
  • 21
  • 5
  • So, you are looking for standard, transport layer encryption methods that handle UDP? – schroeder Aug 30 '18 at 10:28
  • Yes, should based on public private key like tls and not "hardcoded" key encryption – emaayan Aug 30 '18 at 10:32
  • "it has several issues which I believe can causes latency." can you explain that and how other encryption schemes over UDP will not have the same problems? – Patrick Mevzek Aug 30 '18 at 15:18
  • QUIC can be an option but I doubt you will find more implementations of it than of DTLS. "QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion." – Patrick Mevzek Aug 30 '18 at 15:21
  • @PatrickMevzek well, i was reading this: problematic https://security.stackexchange.com/questions/29172/what-changed-between-tls-and-dtls and this section got my eye "in general, anomalous records (missing, duplicated, too early beyond window scope, too old, modified...) are simply dropped. This means that DTLS implementation do not (and, really, cannot) distinguish between normal "noise" (random errors which can occur) and an active attack. They can use some threshold (if there are too many errors, warn the user). " which worried that we'll issues on customer side.. – emaayan Aug 30 '18 at 15:30
  • 1
    If you want to combat all of that you need TCP, not UDP (the paragraph you quote comes after "Datagrams may be lost, duplicated, reordered, or even modified." which is by design in UDP). You are not giving specific data on why you need UDP and not something else. Note that you have also SCTP as an hybrid between TCP and UDP but I am not sure there was anything defined to have all of TLS features in it. – Patrick Mevzek Aug 30 '18 at 17:00
  • UDP is the current protocol being used today, so switching to TCP is not possible, from the description it looks like DTLS will may actually make it worse by dropping packets or exceeding a threshold .. – emaayan Aug 30 '18 at 17:12
  • " from the description it looks like DTLS will may actually make it worse by dropping packets or exceeding a threshold ." no I am not sure you are reading it right. UDP, by essence, may make you loose packets. If you apply over it another records oriented protocol like TCP, you have the problem to deal with missing records. So you just do without, but then you could be attacked, or you drop the connection, or you requery (which means basically doing what TCP is doing). I believe you have contradictory requirements. – Patrick Mevzek Aug 31 '18 at 01:45
  • Why can't a VPN be used? – Klaws May 20 '21 at 09:21

1 Answers1

1

If you can have an additional TCP channel, you could use this channel for TLS and exchange (random) key material which you can use in turn for encrypting the UDP packets. Don't forget to apply a packet counter and possibly timestamps for detecting replay etc. attacks. And use AES-GCM, so you have authentication for (almost) free.

But I don't the part about getting delays because of using DTLS? We are using it in the 500 KB/s range and don't see any delay - having a complete delay of about 1 ms (which is the resolution of the used timestamp^^)

mifritscher
  • 111
  • 1