[Cryptography] TLS/DTLS Use Cases

[ianG]

Taking the contrarian view, as always.

On 1/04/2014 20:10 pm, Bill Frantz wrote:
> In a different thread, pgut001 at cs.auckland.ac.nz (Peter Gutmann) wrote:
> 
>> Documenting use cases is an unnecessary distraction from doing actual
>> work.
>> You'll note that our charter does not say "enumerate applications that
>> want
>> to use TLS".
>>
>> (Yes, someone actually said that).
> 
> As the principal instigator of using use cases to think about the
> proposed TLS 1.3, I have been trying to come up with a small number of
> use cases that cover most of the application space. So far for TLS I have:
> 
>   HTTP -- the original SSL use case
>   Email -- POP, SMTP, IMAP which are not well served by TLS authentication
> 
>   Are there any others that should be included?


Connecting to ones console, aka SSH.  It seems to be the perfect and
perhaps the major use case that actually matches the protocol.  It is
the only one that uses reliable stream, because SSH emulates ones tty,
which going back to the original Unix days, was a concept of one
character being sent per key push all the way to the server (we called
them computers in those days) and then being 'echoed' back to the tty,
and then another character, and then another echo, ad infinitum.

In-order character delivery and echo back again is perfect for a
bi-directional connection.

In contrast:  web aka HTTP is a request-response protocol, being sliced
into a request datagram and a response datagram.  Efforts abound to
layer more RR pairs or datagrams over the top of connections with
keepalives and so forth which may answer why TLS was confused about its
use cases, or may not....  Not a pretty site.

Sending messages aka Email sending is a one datagram going out and a
confirmation coming back.  Order not important, non time-critical.  Etc etc.

Sending messages aka Chat/IM is many datagrams going out and coming
back.  Order here is important, and latency is an issue of sorts, but
the resolution of this is an application decision, so a mistake to bring
it into the lower layers, which also pushes order up to application
(imagine two TLS connections, oops).

Indeed, most of these datagram protocols also aren't fussed about
in-order delivery, and that becomes an app-level decision.  In fact they
often think of it as a bug.

So it is highly debatable as to whether any of the list above are valid
use cases or not, as opposed to vestigial, accidental.  If they are, the
generic use case is probably "layer a request-response datagram protocol
over the top of a (secured) connection."


> I would like to have some for DTLS as well, DTLS applies cryptography to
> UDP.

Ug.  From memory, DTLS was a sort of halfway house to apply TLS back to
datagrams. Which imported all the errors in TLS back to datagrams.  The
result was not going to please.

As per the current thread, its use cases were ... that, it seems,
literally "export TLS back to datagrams."  VoIP for example is lossy and
time critical where as DTLS was not lossy and time non-critical, so
rather a miss.

(Ok, this is from memory, I only read it the once a decade back, maybe
they've fixed that...)


> It seems that DNS might be a good candidate, but can encryption
> even help DNS privacy?


DNS needs to operate below the "named" layer, so it should really be
talking strictly IP# to IP#.  This rather defeats the heavyweight PKI
that rides on the back of the camel.  Also it has happily worked so far
with datagrams so why go backwards?


Maybe these weren't the drones you were looking for...



iang