James A. Donald wrote:
I have been considering the problem of encrypted channels over UDP or
IP. TLS will not work for this, since it assumes and provides a
reliable, and therefore non timely channel, whereas what one wishes to
provide is a channel where timeliness may be required at the expense of
reliability.
This is what Guus was getting at:
- We needed to tunnel data over UDP, with UDP semantics.
SSL requires a reliable stream. Therefore, we had to
use something other that SSL to tunnel data.
To put it in more fundamental terms, TLS assumes that what
you want is a stream. If you want packets, then TLS is a
millstone around your neck. It's not that it can't deliver
packets, but that it forces all your application to think in
stream-mode, which results in messes up and down the stack
(including the human).
The vast majority of applications are not pure stream. The
vast majority are not pure packet, either ... so they are
all somewhere in between.
The selection of where your app is on the spectrum and what
tools you need is the job of the protocol architect;
unfortunately, the prevailing wisdom is that as we only have
a widely deployed stream protocol (TLS) then that should be
used for everything. This has resulted in some "easy wins"
and some "intractable messes" as well the current thread
(repeated into the past and will be repeated into the future).
Advising TLS for a packet delivery requirement is simply
"wrong." You might be "wise" to give that advice, if you
can show some other factors, but that requires ... more
subtlety than simply repeating that TLS has to be used for
everything.
I have figured out a solution, which I may post here if you are interested.
I'm interested. FTR, zooko and I worked on part of the
problem, documented briefly here:
http://www.webfunds.org/guide/sdp/index.html
I've successfully got that going in 3 UDP transport
scenarios, with different key exchange scenarios and
languages. (I was never able to deploy it tho, for business
reasons.) For the most part, the requirements include no
relationship between packets, but an expectation of a return
path ... a.k.a. connections, but without the streaming
assumption ... which means having to relearn how to do
"context" over UDP.
One can compare that approach to the DTLS, which has the
benefit of leveraging SSL technology and history. My
impression was that it assumed too much of the nature of SSL
at the core, so it didn't cover enough of the territory to
satisfy me. But if it becomes widely deployed, that may be
the better bet than designing another one or a home-brew.
Deployment counts over elegance, most times.
iang
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
