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 [EMAIL PROTECTED]
