[Cryptography] TLS/DTLS Use Cases

Jerry Leichter leichter at lrw.com
Tue Apr 1 22:31:54 EDT 2014


On Apr 1, 2014, at 7:40 PM, Matthew Ghali <mghali at snark.net> wrote:
Bill Frantz asked:
>> Are there any others that should be included?
> 
> XMPP, LDAP, RDP/VNC, Database client and replication (MySQL, Postgres, MS, MongoDB), Memcache, FTP, Syslog (DTLS too), VPN (ditto), IPP/Jetdirect/lpr, BGP (someday), SIP, SDP, RTP, STUN pop up in Google. 
"You use that word but I don't think you know what it means."

These are not use cases.  Neither are many of the others that this thread has drawn.  These are particular protocols that live on top of a reliable stream transfer method, i.e., TCP.  Not a singe one of them had even been conceived at the time TCP was designed, and yet TCP supports them all.  If TCP had to wait for requirements from a long list of "use cases" like this, we would still be lacking a spec.

Use cases are particular patterns of communication with, one thinks, distinct requirements.  IanG gave some examples - things like request-response protocols (one-shot or repeated) and character streams.

An interesting thing about SSL is how badly it was designed to match any of the use cases to which it was initially applied.  HTML was originally a one-shot request-response protocol, but SSL has expensive connection setup was - and there was no session continuation mechanism.  At a fundamental level, TCP chose to transmit reliable streams, when competing protocols were record-based.  So SSL (and TLS to this day) provide on top of TCP?  A record-based protocol.  This makes it unnecessarily difficult to take existing code that talks directly to TCP and make it talk to SSL instead.

A number of years ago, I had to deal with exactly this situation:  A proprietary TCP-based protocol that we needed to make secure.  For a long time, we had customers route their connections over SSH, but they ended up wanting us to provide the crypto built in.  (More fools them - SSH was almost certainly more secure.  But never mind.)  Anyway, I designed and implemented a secure byte stream protocol that could replace TCP more or less 1-1.  (No, it didn't use a stream cipher.  Down at the bottom, it really was exchanging 8-byte encrypted blocks; but blocks could be "short", with only some of the (decrypted) data actually meaningful.)  Worked quite nicely.


IPSec has many faults - so many as to render it unusable - but it did get one thing right:  To most code, an IPSec socket looks just like a plain TCP socket.  Anything that talks TCP can talk TCP "securely" over IPSec with essentially no changes.  ("Securely" in quotes because it's a rather specialized notion of "securely".)

I know it's not going to happen, but in an ideal world, TLS3 would be as easy to add to a TCP program as SSH tunneling when you've got all the port information and such.  Key negotiation and such should be separable from the rest of the protocol:  If you want it done in-line, fine; if you need to run it separately because you're not in a position to modify the existing connection code, fine.
                                                        -- Jerry



More information about the cryptography mailing list