On Wed, Oct 01, 2003 at 10:20:53PM +0200, Guus Sliepen wrote:
> You clearly formulated what we are doing! We want to keep our crypto as
> simple and to the point as necessary for tinc. We also want to
> understand it ourselves. Implementing our own authentication protocol
> helps us do all that.
> Uhm, before getting flamed again: by "our own", I don't mean we think we
> necessarily have to implement something different from all the existing
> protocols. We just want to understand it so well and want to be so
> comfortable with it that we can implement it ourselves.

In that case, I don't see why you don't bend your efforts towards
producing an open-source implementation of TLS that doesn't suck.
If you insist on not using ESP to encapsulate the packets -- which in
my opinion is a silly restriction to put on yourself; the ESP encapsulation
is extremely simple, to the point that one of my former employers has a
fully functional implementation that works well at moderate data rates
on an 8088 running MS-DOS! -- TLS is probably exactly what you're looking

Note that it's *entirely* possible to use ESP without using IKE for the
user/host authentication and key exchange.  Nothing is preventing you
from using TLS or its moral equiavalent to exchange keys -- and looking
at some of the open-source IKE implementations, it's easy to see how
this would be a tempting choice.  Indeed, there's no reason your ESP
implementation would need to live in the kernel; I already know of more
than one that simple grabs packets using the kernel's tunnel driver, for
portability reasons.

However, if for what seem to me to be very arbitrary reasons you insist on
using an encapsulation that's not ESP, I urge you to use TLS for the whole
thing.  As I and others have pointed out here, if you're willing to *pay* 
for it, you can have your choice of TLS implementations that are simple, 
secure, and well under 100K.  Compare and contrast with the behemoth that 
is OpenSSL and it's easy to see why you wouldn't want to use the 
open-source implementation that is available to you now, but there is no 
reason you could not produce one yourself that was much less awful.

You say that you object to existing protocols because you want simplicity
and performance.  I say that it's not reasonable of you to blame the
failures of the existing *open-source implementations* of those protocols
on the protocols themselves.  I think that both the multiple good, small,
simple commercial SSL/TLS implementations and the two MS-DOS IPsec
implementations are good examples that demonstrate that what you should
object to, more properly, is lousy software design and implementation on
the part of many open-source protocol implementors, not lousy protocol design
in cases where the protocol design is actually quite good.  So if you're
going to set out to fix something, I think if you're trying to fix the
protocols, you're wasting your effort -- there are existing, widely
peer-reviewed and accepted protocols that are *already* about as simple
as they can get and still be secure the way users actually use them in the
real world.  I think that it would make a lot more sense to fix the lousy 
implementation quality instead; that way you seem much more likely to 
achieve your security, performance, and simplicity goals.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to