Tinc's response to "Linux's answer to MS-PPTP"

[M Taylor]

On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote:
> 
> > Truncated MAC
> > tinc will continue to use only the first 32 bits by default.
> Simply put this is unacceptable from a security standpoint. The view taken
> is that the extra 128 bits represents a significant overhead in the
> communication. So I did the math, sending the extra 128 bits over a 52kbs

It appears Guus Sliepen (and/or Ivo Timmermans) are worried about the
tinc protocol overhead per packet. This reduces the size of the data 
payload per packet, which could impact perforcemance due to IP
fragmentation. Because the IP packet length is often restricted due
to Ethernet frame size (1500 bytes), it can is more efficient to design
the protocol so each UDP datagram is a full IP packet (1500 bytes Ethernet
frame minus the 20 bytes for IP header, and 8 bytes for the UDP header) with a 
payload of 1472 bytes.

Perhaps a HMAC per "chunk", rather than per the payload of a single UDP
datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of 
payload may work. This will increase latency.

> > Authentication protocol

This should be redone from scratch, I would look at either using
Diffie Hellman Key Exchange combined with digital signatures or the updated
Needham Schroeder Public Key Protocol. Exchange two symmetric keys,
one used for bulk data encryption, the other used for the HMAC
authentication. 


> > [VPNs] work best with unreliable datagrams
> Ummmm, do you realize how dumb that sounds?

I expect this is a reference to "Why TCP Over TCP Is A Bad Idea"
<http://sites.inka.de/~bigred/devel/tcp-tcp.html>

> > Both SSL and SSH have had their security
> > problems . . , as perfect as Peter Gutmann would let us believe.
> They may not be perfect but in neither case can Mallet do as much damage as
> easily, even the recent break in OpenSSH did not allow a compromise as big
> as even the smallest of the problems briefly explored in tinc.

Oh, and they fixed their flaws. SSHv1 is not recommended for use at all,
and most systems use SSHv2 now which is based upon a draft IETF standard. 
SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF
standard.

If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their
high tolerance for unncessary weakness, I think tinc 2.0 could end up being
a secure piece of software. I hope Guus and Ivo circulate their version 2.0 
protocol before they do any coding, so that any remaining flaws can be easily 
fixed in the paper design without changing a single line of code, saving time 
and effort.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com